This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
On 06/10/2012 04:12 AM, Helmut Eller wrote:
* Jamison Hope [2012-06-10 05:08] writes:
#!null needs to remain a distinct value, though, if only so that we
can pass
it to Java code.
I also think that representing nil as the JVM null value would be quite
elegant. There are ifnull/ifnonnull instructions that would be useful
for conditionals. Also CL variables/slots/arrays that need to be
initialized to nil would match the JVM rules quite neatly.
It would be challenging.
First, we'd have to change the list API so the empty list is represented
using null. Either we'd be incompatible with Scheme, or Scheme would
have to change as well. That means changing LList.Empty to null. It
also means that the empty list would not be instanceof java.util.List
or gnu.lists.Sequence (though of course null is compatible with those
types). This is a big change, and it might even be worth it, but
it's somewhat scary.
Second, null would have to be an instance of the symbol type.
I.e. (symbolp x) is (x instanceof gnu.mapping.Symbol || x == null).
Any of the standard symbol functions may have to special-case null.
(Which isn't a big deal, since we already do that.)
Third, note that Scheme treats #f as the default/special/missing
special value, not '(). This Java null corresponds more closely
to Scheme # rather than Scheme '(). But if Scheme false is
Java null, while the empty list remains LList.Empty we have
an incompatibility with Common Lisp that seems harder to bridge
(convert) than for booleans.
--
--Per Bothner
per@bothner.com http://per.bothner.com/