This is the mail archive of the kawa@sources.redhat.com 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: kawa-java string compatibility proposal


Per Bothner wrote:

> But suppose a Scheme programmer wants to annotate the parameter type
> or local variable: It's a <string>.  I can do string-set! on a Scheme
> string.  I cannot do that on a j.l.String.  I don't understand how you
> think "coercion" can do the right thing here: a coercion would have to
> make a *copy* and it's obviously wrong to mutate the copy.

I don't think that is so.  The Scheme string situation seems pretty
clear that you must create a "new" string to mutate it.  I think it
meets expectations, is very Schemey, and good safe programming practice
for literal strings and <string> to be immutable.  If you're gonna use
parameter typing with a string mutator then you should declare it to be so.

(define (string-set! (s :: <mutable-string>) (k :: <number>) (c ::
<character>) ...)

Coercion does the right thing here which is that there is no coercion.
If s is not an instanceof j.l.StringBuffer it's gonna fail (as R5RS says (string-set! "***" 1 #\?) is an error and so is (string-set! (symbol->string 'foo) 1 #\?) 6.3.3). To get a <mutable-string> you use one of the methods specified to return a "new" string.


And if you declare your type and you use <string> you get an immutable
string (j.l.StringBuffer.toString).  I don't read R5RS as saying strings
are normally mutable, I think it says the reverse (immutable unless you
make a new copy and keep it somewhere).

>> I would have <abstract-string> for j.l.CharSequence.
>
> And what's the fallback if we don't have CharSequence?

gnu.lists.CharSeq (or CharSequence) using the Java-version preprocessing, or maybe nothing (j.l.Object). CharSequence could be used by preprocessing just the import. I don't have a preference for whether Kawa should use Java strings using Java < 1.4. I suspect it would be easier (as in neceassry - particularly for collections compatibility, see below) to use Kawa's strings.

> It could be a "union type" - but we don' have that, yet. See below.

I don't think any union is needed since only (string? s) needs to know
that two different classes are Scheme strings.

> It may be more work though ...
>
> Plus, right now <string> is a sub-type of <sequence>, and that follows
> trivial since <FString> is a sub-class of gnu.lists.Sequence.  That's
> a valuable feature - it's required for Common Lisp and SRFI-44.
> Again, unless/until Kawa gets better support for union types.

Well, that is a bit ugly. j.l.CharSequence does not implement j.u.List.
That is obviously a bug and also nothing we can do to fix it (other than that sequence stuff has to test for j.l.CharSequence).


But since you bring that up, I'm sure you won't be surprised that I'ld like to see Java Collections work harmoniously as Kawa/SRFI-44 collections, vectors, and lists too.

I feel Kawa is the best thing for Java no one has ever heard of. I think Kawa would have a much better chance of catching fire with the Java community (which is carrying on with the usual track of reinventing all the things Kawa/Scheme does with tags, generics, scripting, and XML) if it gave first class support for Java types instead of using it's own type tree. The reason for that is the scenario for Kawa to become widely used is folks adding dynamic extensions to existing Java code. Right now, working with existing (or new code by Java programmers) Java code is awkward at best. If Java Strings and Java Collections worked seamlessly with Kawa a lot of special Java interfacing would disappear and work beautifully (ala XPath and JavaBeans in JXPath - but why-o-why 1-based indicies *sigh*).

Jim


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