This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: kawa-java string compatibility proposal
Jim White wrote:
Per Bothner wrote:
Jim White wrote:
Per Bothner wrote:
But wouldn't the way to go be to have <string> be j.l.String
I assume you mean <immutable-string> be j.l.String, where
<string> == union(<immutable-string>, <mutable-string>)
No, I don't believe that is necessary. j.l.String coercion will take
care of the cases where the programmer doesn't know and doesn't care
about the distinction between mutable and immutable.
But suppose a Scheme programmer wants to annotate the parameter type
or local variable: It's a <string>. I can do string-set! on a Scheme
string. I cannot do that on a j.l.String. I don't understand how you
think "coercion" can do the right thing here: a coercion would have to
make a *copy* and it's obviously wrong to mutate the copy.
I would have
<abstract-string> for j.l.CharSequence.
And what's the fallback if we don't have CharSequence?
It could be a "union type" - but we don' have that, yet. See below.
I think of an immutable string as one that has the same interface as a
mutable string but if you try to mutate it you get a runtime exception.
The other way is compatible with static typing and I believe better
fits with object-oriented design principles.
But this is moot as I prefer the
Java-based scheme above for Kawa.
It may be more work though ...
Plus, right now <string> is a sub-type of <sequence>, and that follows
trivial since <FString> is a sub-class of gnu.lists.Sequence. That's
a valuable feature - it's required for Common Lisp and SRFI-44.
Again, unless/until Kawa gets better support for union types.
Union types may be needed for XQuery (at least for XQuery's "static
typing feature"), so Kawa may need those anyway. One option is to
defer this issue until we have working union types - but that will
take a longer.
Of course union types are less efficient that a plain 'instanceof'.
Also, any plan to implement <immutable-string> using <java.lang.String>
will require first changing the implementation of <symbol> to be
<gnu.mapping.Symbol>. That is somewhat more straight-forward, since it
doesn't require union types, but it will break some code. What are
people's feeling about this?
--
--Per Bothner
per@bothner.com http://per.bothner.com/