This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: features inconsistency


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]