Re: kawa-java string compatibility proposal

[Jim White <jim at pagesmiths dot com>]

Per Bothner wrote:

> Vadim Nasardinov wrote:
>
> > StringBuffer is significantly faster than char[] in many cases.
> > Converting a char[] instance to a String via new String(char[]) always
> > involves copying.
> > Converting a StringBuffer to String via StringBuffer#toString()
> > involves no copying, provided the StringBuffer instance is never
> > mutated after you call toString() on it.
>
> True.  On the other hand, StringBuffer has extra non-trivial overhead,
> including synchronization.  Using StringBuilder reduces the overhead,
> but doesn't remove it, and is Java5-specific.  And char[] does have
> semantics closer to Scheme strings.

I don't believe having <mutable-string> be something other than 
j.l.StringBuffer flies on the basis of improved performance.  Mutating 
strings (or any string operations other than comparison) are relatively 
rare in the scheme of things.  And if an application does do a crazy 
amount of string mutation and is getting performance tweaked, they are 
gonna be well aware of Kawa's Java implementation and are free to use 
whatever non-standard class they like.

The most heavy use of strings in Kawa is made in compilation and 
j.l.String is already used there.  In fact by switching to g.m.Symbol 
there is the potential of using a fast non-copying implementation tied 
to the lexer (via CharSequence).  The compiler could even use 
java.nio.CharBuffer with a memory mapped source file - and if you wanted 
to use that code without knowing a priori whether the file might close 
when the symbols are still needed, a toString pass could be made on the 
symbol table in that case.

Jim White