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: 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/


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