Re: [Kawa-commonlisp-dev] Switching to Guile's #nil

[Per Bothner]

On 06/18/2013 08:11 PM, John Cowan wrote:
> It sounds like you've argued yourself back to the Guile position:
>
>    (eqv? #f #!null) => #f
>    (eqv? '() #!null) => #f
>    (null? #!null) => #t
>    (if #!null 1 2) => 2

Well, I am concerned about the performance cost.

Apropos here a a related note from John Rose:
http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010171.html

(C2 is the optimizing JIT compiler:
http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html)

To get a handle on how expensive this change to "is-true" is,
I added print statements to the compiler when it compiles a
"general" truth-test - i.e. when the compiler currently emits
a test against Boolean.FALSE.  Some very preliminary results
suggest that many tests (most?) do get optimized to not need
the general object test.

Some cases that are not optimized are arguably compiler bugs -
i.e. places where the compiler misses a fairly simple optimization.
For example:
  (if (> x y) ...)
The compiler would generate code to call a method that returns
an Object, when it should call a method that returns an immediate
boolean.  I've fixed this one, and I'm looking at some others.

I may be coming around to the Guile approach *assuming*
we look at the performance costs and evaluate possible
optimizations.

> > Perhaps start by replacing
> > (xx == LList.Empty) by (LList.isEmpty(xx)) lots of places.
>
> Well, as I also said to begin with, this makes it cost more to
> evaluate either truth or emptiness, no matter how you look at it.
> The result is that pure Scheme code probably runs slower (modulo
> JIT effects).

This seems hard to avoid with the "Guile approach": Unless you
know a list is a "Scheme list" then you have to test for both
LList.Empty and #!null.

Code that does:
  (eq? lst '())
will be faster than
  (null? lst)
but the latter also handles Lisp lists.  Is that a good tradeoff?

One could make "better Scheme/Lisp compatibility" a configuration
option.  Not clear what the default should be.  Of course one
might argue that interpreting #!null as false and allowing
it as the end-of-list are "friendlier" and less surprising,
even to pure Scheme programmers.
--
        --Per Bothner
address@hidden   http://per.bothner.com/