Re: Strings and Characters in Kawa

[Per Bothner <per at bothner dot com>]

Nigel Dolby wrote:
> The Java and Scheme functionality overlaps in these areas, so one has to 
> choose whether to employ Java strings or Scheme strings. On the basis 
> that Java is a more elementary level of functionality than Scheme and 
> has quite rich string-handling capabilities which should be fairly 
> efficient, it seems appropriate to use Java strings.

I gather you understand the basic conundrum: Scheme strings are mutable
(can be modified) while java.lang.String objects cannot be.  So a
function like string-set! cannot be implemented on top of Java Strings.

> But if I try to give a Java string to a Scheme function that expects a 
> string I get a type error. Similarly, if I try to give a Scheme 
> character to a Java function that expects a character, the function 
> fails (with no error message).

To some extent that in evitable - but we can be smarter.

> The following Kawa forms exhibit these problems. The code is intended to 
> accept a line of text from an input file, represented here by making a 
> Java string, to locate the first space in the line, and then to create a 
> Kawa symbol from the characters prior to the space.
>
> (set! jstr bfoo.scm)
>
> (set! sppos (invoke jstr 'indexOf #\space))
>  [fails, but replacing #\space by 32 works, correctly returning 6]

Hm.  Kawa seems to convert #\space to the Java string "' '" (with extra
quotes) and searches for that, using String.indexOf(String).  Not sure
why it's doing this - at least it should have used the Java String " ".

Could you add a entry in the Kawa bugzilla database, and I'll thunk
about it?  This may be tricky, because String.indexOf takes an *int*,
not a char, and Kawa does not know that the int version is a better
match than the indexOf(String).  (Using java.lang.Character has the same
problem.)

> (set! typesymb (string->symbol (invoke jstr 'substring 0 sppos)))
>  [generates type error]
>
> I would like to understand exactly what is (or is not?) going on, and 
> how to convert strings and characters between Java and Kawa and vice 
> versa (or perhaps how to avoid any need for conversion). It would also 
> be interesting to know whether there are reasons favoring use of Scheme 
> strings/characters or Java strings/characters in Kawa (although some 
> amount of conversion is probably inevitable). Thanks.

There is a plan to convert Kawa to use:
gnu.mapping.Symbol - for Scheme symbols
java.lang.String - for literal/immutable Scheme strings
gnu.lists.FString - for mutable Scheme strings

The Scheme <string> type would become <java.lang.CharSequence>.

There are a couple of tricky issues:
* What to do on pre-1.4 Java systems that don't have CharSequence.
Ideally we'd use a "union type" - a union of java.lang.String
and gnu.lists.FString.  Or just use gnu.lists.FString.
* What conversions to implement between these types, and how
to do so.  Ideally I'd like a better language-specific
type-conversion framework.
* Plus it's just a lot of changes that have to be done more-or-less
at once.

This was discussed late last year.

The use of gnu.text.Char instead of java.lang.Character is separate.
The main problem with the latter is that it doesn't support characters
not in the Basic Multilingual Plane (i.e. values above \uffff).  But
we should fix Kawa so it automatically converts between these types,
to the extent that it doesn't already do so.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/