Re: GSOC | Extending Common Lisp support

[Jamison Hope <jrh at theptrgroup dot com>]

On Jun 9, 2012, at 4:41 PM, Charles Turner wrote:

> On 9 June 2012 18:58, Jamison Hope <jrh@theptrgroup.com> wrote:
> > It *seems* like that's the purpose of defaultValue in
> > get(Object defaultValue), right? Except that the default value is
> > ignored:
>
> Yeah, I had considered implementing something "ad-hoc" like this, but
> just thought it best to ask for cleaner ways.
>
> Apropos the #!null stuff, it's more pervasive than just the result of
> thread locations, there's a few places already where lisp calls a java
> method returning null, which means #!null in Kawa, but it would make
> more sense if it return nil in CL, () in Scheem... I imagine there are
> deeper reasons for #!null, but I don't see any immediate reason why
> such a translation couldn't be implemented. For the time being I'm
> using
>
> (defmacro jnullp (obj)
>  `(eq ,obj #!null))
>
> The idiom is used in kawa/lib/files.scm, so I guess it's A Fact Of  
> Life.

Yes. I have toyed with the idea of an extension to Scheme which would  
treat
#!null as false, but I've never coded anything up for it. NULL==0==false
can certainly be handy in C/C++/ObjC, and it makes some logical sense  
here,
too (cf. Groovy's Elvis operator:
<http://groovy.codehaus.org/Operators#Operators-ElvisOperator>).

Common Lisp already unifies () and #f as NIL, so it would make some  
sense
for null to be in there, too. NIL in CL and #f in Scheme are used as  
return
values in a way idiomatically similar to how null is used in Java.

#!null needs to remain a distinct value, though, if only so that we  
can pass
it to Java code. But that doesn't mean that we have to treat #!null as  
true
*in a boolean context*. Standard Scheme says that the only false value  
is #f,
and that in particular '() is true, but as Java's null is outside the  
scope
of the Scheme spec, in principle we could go either way with it.

There's certainly a valid argument that it's more in the spirit of  
Scheme
to say "it's not #f, so it must be true" (and that's how Kawa currently
treats it), but CL already chooses practicality over purity, so...

But for the moment, just stick with your jnullp, methinks.


> Do you have any thoughts on this problem:

[snip]

> This all works nicely from the REPL (with FIND-PACKAGE evaluated in
> the REPL, not primitives.lisp...)

[snip]

> However, when I pop this definition in primitives.lisp, dragons
> appear. It compiles OK, but when I start up CL, I see stack traces of
> the form
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at java.lang.Class.forName0(Native Method)
>        [...]
> Caused by: cannot load gnu.commonlisp.lisp.primitives
> 	at gnu.expr.Language.loadClass(Language.java:431)
> 	at gnu.commonlisp.lang.CommonLisp.initLisp(CommonLisp.java:118)
> 	at gnu.commonlisp.lang.CommonLisp.<clinit>(CommonLisp.java:90)
> 	... 5 more
> Caused by: primitives.lisp:135:9: unbound location eq (property  
> (function))
> [...]

Looks like a boostrapping problem with the order in which stuff is  
getting
loaded by initLisp(). You've got a  
loadClass("gnu.commonlisp.lisp.primitives")
in the same place as SVN's loadClass("...PrimOps"), right? But the
function #'eq isn't defined until the defun() later on.

So, it gets confused loading primitives.class, and throws that
(uncaught) "unbound location" exception, leading to the
initialization error.

> Wat? After doing this, an attempt to compile PrimOps.scm results in
> the following hilarity:
>
> PrimOps.scm:24:24: warning - error loading class clisp:boolean - Could
> not initialize class gnu.commonlisp.lang.CommonLisp not found

Since there was an error during CommonLisp.class's initialization,
the class failed to load and is inaccessible. Since it needs the
CommonLisp class to resolve |clisp:boolean|, you get an error there,  
too.

> [ ... several more times ... ]
> PrimOps.scm:120:20: warning - no declaration seen for clisp:boolean
> PrimOps.scm:140:21: warning - no declaration seen for clisp:boolean
>
> Hm, I haven't the foggiest notion why this is happening!

Move the loadClass("primitives") down after the defun("eq") and it  
should
be much happier.

> On the plus side, package initialisation/searching is working OK from
> the REPL. I hope to try out actually making symbols in namespaces and
> testing the inheritance stuff next.

Good job so far!

> Charles.


Jamie

--
Jamison Hope
The PTR Group
www.theptrgroup.com