This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: GSOC | Extending Common Lisp support
On Jun 10, 2012, at 1:01 PM, Per Bothner wrote:
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.
Quite so, which is why I avoided that suggestion originally. I quite
like the idea of #!null being treated as false in a boolean context,
as it fits the notion (common to both Scheme and Lisp) that "the default
is false".
But I am also fond of the idea of Scheme lists and Common Lisp lists
having the same representation. Assuming we want to maintain this
Scheme/Lisp list compatibility, then we have to respect that
(if '() "true" "false") evaluates to "true" in Scheme, but "false" in
CL.
That means that if we use #!null to represent '(), then Scheme MUST
treat #!null as true.
I briefly looked at what would be required to treat #!null as false.
At first glance, changing Lisp2.java's isTrue(Object) to
public boolean isTrue(Object value)
{
return value != null && value != FALSE;
}
(and a similar change in Language.java for Scheme) seemed like it
should do it, and it works sometimes:
#|kawa:1|# (if #!null t nil)
()
But it fails if the test can't be constant-folded away:
#|kawa:2|# (defun foo (x) (if x t nil))
#|kawa:3|# (foo #!null)
t
As it turns out, ConditionalTarget#compileFromStack does not defer to
isTrue(): instead it expects there to be exactly one false value per
language, which it retrieves with language.booleanObject(false), and
then it does an object equality check to determine falsehood.
So it looks like either change, using #!null for () or treating #!null
as false [which are mutually exclusive changes if CL lists are S lists],
is going to be nontrivial.
For now (and by "now" I mean the duration of GSOC 2012) I'll recommend
keeping things as they are.
-Jamie
Oh, but you know what would be spiffy? Making "null as false" a
compile option:
(with-compile-options null-as-false: #t
(let ((o (some-java-object:get))) ;; returns null by default
(if o ...)))
--
Jamison Hope
The PTR Group
www.theptrgroup.com