This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
string and symbol values [was: class and type values]
- From: Per Bothner <per at bothner dot com>
- To: Jim White <jim at pagesmiths dot com>
- Cc: "'Kawa List'" <kawa at sources dot redhat dot com>
- Date: Mon, 12 Feb 2007 18:10:15 -0800
- Subject: string and symbol values [was: class and type values]
- References: <45CCF06F.7090703@bothner.com> <45CD03A9.4040206@pagesmiths.com>
Jim White wrote:
The long sought change so that "Foo" instances
are java.lang.String is needed for the same reason.
I started looking into this, and I've gotten for enough
that it looks like it will actually happen: I've got
Kawa building, and am making my way through the testsuite.
The basic design:
Scheme string literals become java.lang.String.
Writable strings remain gnu.lists.FString.
Strings in general are java.lang.CharSequence.
Scheme symbols are gnu.mapping.SimpleSymbol, which
is a new sub-class of gnu.mapping.Symbol.
The downside/problem:
Some exiting code will break. I don't know whether a
"compatibility mode" is feasible. At the very least
we'll break equal? between symbols and java.lang.String
values.
It may be possible to allow passing a SimpleSymbol to a
function/method that expects a java.lang.String and/or vice versa.
That might alleviate may (but not all) of the compatibility
problems. It could be optional, since it would fail to
catch some errors, and would affect overload resolution.
I could try that, if people want it.
I haven't looked at what to do for JDKs older than 1.4,
that don't have java.lang.CharSequence. I could use a
"union type", but I don't know how difficult that would
be. I think I may just use FString for string literals
in that case, which means java.lang.String won't be a
Scheme string. This is not an issue for anyone running
JDK 1.4 or newer. Perhaps I should give up the pretense
of supporting older JDKs - I certainly don't test them.
The question is how painful this will be. One option is
to make this change in a branch. Another option is to
have a configuration option for the old behavior. Both
of these will make things more difficult for me.
Comments?
--
--Per Bothner
per@bothner.com http://per.bothner.com/