Re: kawa-java string compatibility proposal

[Chris Dean <ctdean at sokitomi dot com>]

Per Bothner <per@bothner.com> writes:
> Also, any plan to implement <immutable-string> using <java.lang.String>
> will require first changing the implementation of <symbol> to be
> <gnu.mapping.Symbol>.  That is somewhat more straight-forward, since it
> doesn't require union types, but it will break some code.  What are
> people's feeling about this?

I don't know what I think about the whole mutable/unmutable/etc string
types, but I do like the idea of decoupling <symbol> from j.l.String.
It would break my code, but is probably worth the pain.

There is a bug I see fairly regularly related to this: Sometimes folks
assume that a j.l.String value returned by a Java method is a Scheme
symbol.  That semantically not true of course, but their test cases
often give the answer the expect:

    (eq? 'red (some-class:get-color my-object))  => ??

If get-color returns the j.l.String "red" is the expression #t or #f?
Well, it depends.  This is an annoying bug because it often passes in
our unit tests but fails in a production setting.  

Regards,
Chris Dean