Re: kawa-java string compatibility proposal

[Per Bothner <per at bothner dot com>]

Before getting into details, here is an idea that I think may help.
I don't think it's very different from Steve's ideas, but I think
it is useful to think in terms of "data types" rather than just
"operations".

Some Scheme implementations provide two kinds of strings:
Mutable (modifiable) and immutable (constant) strings.
A Scheme string literal yields an immutable string,
while functions like string-length and string-ref work
both both kinds of strings, while functions like
string-set! and string-fill! only work on mutable strings:
Applying the latter on an immutable strings throws an exceptions.

We can distinguish mutable and immutable strings by implementing
them using different classes, or we can ue the same class with an
extra "mutable" flag.

What I think we want is maximal interoperability between Java strings
and immutable Scheme strings.  In fact one tempting possibility is to
represent immutable Scheme strings as Java Strings, but there are
some disadvantages/problems, which I'll discuss later.

My suggested "coercion" rules:
* A Scheme string, either mutable or immuatable, is OK in a context
requiring a Java String.  The compiler/run-time effectively does a
'toString' operation.
* A gnu.mapping.Symbol (i.e. a JEmacs or CommonLisp symbol) can
also be automatically converted to a Java String, but only if
the "namespace" or "package name" is empty.  (This would be
needed for compatibility if we change the representation of
Scheme symbols from String to Symbol.)
* A Java String is OK in a context requiring an immutable Scheme
string.  "Coercing" a Java string to a Scheme string creates an
immutable Scheme String.
* A Java String is not OK in a context requiring mutable Scheme
string.  This may be "caught" at compile-time or run-time, in
various ways.  Kawa may allow the coercion at the type level, and
create an immutable Scheme string; in that case we'd get the
error when we try to modify the immutable string.  Alternatively,
we can view this as a type convesion error, with "mutable-string"
as a sub-type of "string", and disallow that.

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.

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

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.

String literals would be FString, but make-string copy-string
etc return a VString.

We'd allow implicit coercion from FString to java.lang.String,
and from String to FString - but not to VString.  In both
cases the coercon works by copying.  (The implementation of
FString could optionally cache the String, though I'm not sure
that is best.)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/