features inconsistency

[Gerardo Horvilleur]

I've been thinking if it wouldn't be better to have a special Java  
class to represent Kawa symbols instead of java.lang.String. Both  
Kawa symbols and Java strings are immutable objects that contain a  
string of characters, but I'm not sure it is "right" to use Java  
strings as the internal representation for symbols in Kawa.

I believe that using a custom class for Kawa symbols would have the  
following benefits:

1. No more broken symbol serialization (Java strings are not interned  
on deserialization).

2. It might simplify the semantics of calling a Java method which  
returns a String.

I am aware this might not be a trivial change in Kawa's  
implementation :)

Gerardo Horvilleur
mago@mundojava.com
5813-0830



On Dec 22, 2005, at 11:10 AM, Per Bothner wrote:

> Victor Anyakin wrote:
>> Greetings to All,
>>   I would like to share my experience using Kawa interpreter.
>>   Everything seems fine, but, it seems to me somewhat odd, how  
>> strings
>>   are processed.  There are lots of cases, when strings returned from
>>   java methods (of type <java.lang.String>) are not accepted by Kawa
>>   routines (like string->number).  Each time I pass or receive a
>>   string, extra care has to be taken, in order to ensure, that it  
>> will
>>   be normally processed.
>
> Yes, this is annoying, but it is to some extent unavoidable, since
> java.lang.String objects are immutable, and Scheme strings can be
> modified.
>
> I do hope to more automatically convert between the two types, but
> I haven't worked out the details.  Note automatically converting from
> a Java string to a Scheme string is dangerous, because if someone
> modifies the resulting string they may get non-obvious  
> inconsistencies.
> Adding a "non-modifioable Scheme string" type is probably the  
> solution.
>>   One more issue are plain java arrays.  I find it inconvenient to
>>   define (primitive-array-get <type>) and so forth every time I wish
>>   to process plain java array.
>
> Yep.  The syntax is clunky.  You might want to define some type- 
> specific
> macros for your application.
>
> I have been thinking about an alternative syntax.  I'm leaning towards
> using function-call syntax, but that is a rather radical change:
>
> (define my-arr (<int[]> length: 10))
> (set! (my-arr 3) (my-arr 5))
> -- 
> 	--Per Bothner
> per@bothner.com   http://per.bothner.com/