Re: kawa-java string compatibility proposal

[Jim White <jim at pagesmiths dot com>]

Per Bothner wrote:
> ... 
> Given this model, how shoudl be implement the two kinds of strings?
>
> Using java.lang.String for immutable strings is a possibility, but
> it has some problems:  Current Kawa represents Scheme symbols using
> java.lang.String, and it would have to be changed (to use
> gnu.mapping.Symbol, like JEmacs does).  This might break a lot of
> existing code, plus it would require a lot of work on my part.

I appreciate the big impact that such a change would have and would be 
reluctant to make it too.  But I think that if Kawa's string handling is 
going to be changed at this point it should be fixed in the best 
possible way.

The problem with retaining the use of j.l.String for symbols is that it 
continues the practice of Kawa programmers relying on knowledge of this 
implementation detail.  That is why it would break existing code and 
there will just be more of it as time goes on.  Kawa having to use a 
special class for the special purpose of symbols is entirely sensible 
(of course I can relate to the compiler effeciency consideration that 
led to the choice of j.l.String too).

Given that the real big win is for Kawa/Java programmers getting what 
they expect ("literal" and <string> are j.l.String), I doubt it is 
worthwhile making significant changes that don't achieve that.  Adding 
coercion where the compiler can figure it out it is needed is certainly 
a good thing though.

> Another problem with using java.lang.String is that it would make
> the Scheme <string> type be a "union type" - a union of two
> unrelated Java classes.  Neither Java or Kawa deal well with unions.

True, but AFAICT you're already committed to dealing with the 
interoperability/coercion issues.

> We could define <string> as <java.lang.CharSequence> but that means
> losing the ability to run with JDK 1.3 or older.

I like that idea.  Since the build (preprocessing for Java version is 
already done now, we just need a fancier tool) can keep Kawa's code from 
becoming obtuse, I think it is the best approach since it is Java fixing 
the exact problem you're looking at and doing it the right way.

But wouldn't the way to go be to have <string> be j.l.String and 
<mutable-string> be j.l.StringBuffer?  My understanding of R5RS 6.5.3 
(string-set! examples) is that literals are immutable.  Isn't that what 
we all want?

> A better solution is to use two - or three Java classes, for mutable
> strings, immutable strings, and a common super-class.  There are
> various ways of doing this, but I'm leaning towards:
>
> gnu.lists.FString // <string>
> gnu.lists.VString extends FString // <mutable-string>
> ("VString" for "variable string".)
>
> The "type" of immutable strings would be the "differnce"
> between <string> and <mutable-string> - i.e. those whose
> class is FString.

I believe this derivation is upside down.  Either mutable and immutable 
strings can be siblings of an immutable class (as in the 
j.l.CharSequence tree), or you can derive an immutable string from a 
mutable one (which I think is best and they had to compromise because it 
would break backwards compatibility).

But you can't derive mutable strings from immutable ones (because you 
can't find out whether it is immutable by it's class which is very 
important information and allows you to pass an immutable object to a 
method that requires mutability).  If you could, we and everyone else 
would have been creating subclasses of j.l.String like crazy.

Jim White