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

[John Cowan]

Per Bothner scripsit:

> I suspect that I1 and I2 are more important than I3.

Well, there are an awful lot of libraries for Lisp too that Schemers
might like to have access to.

> Nil is of course a nasty problem - there is no good
> interoperability answer.  Currently, Kawa-Lisp uses
> LList.Empty for nil.  My rationale was that if we need
> to pass data between Scheme and Lisp, it is harder to
> convert lists if we used a different representation of
> the empty list, while "atoms" (symbols and booleans)
> are easier to translate.  

Overall I agree with that rationale.  The trouble with it is
that a Scheme procedure calling a Lisp function doesn't know
whether to interpret the () it gets back as the empty list or
false.  Having a separate representation avoids this problem.

> Note Kawa-Scheme uses #!null for Java null, so I don't think
> we need a #nil syntax (unless for Guile compatibility).

No problem; I don't care about the specific lexical syntax.

> (3) is easy - I agree #nil (java null) should be a symbol in Lisp
> but not Scheme.  However, note we  need a "shadow symbol"
> for nil that is gnu.mapping.Symbol.  

Sure.

> - Lisp nil is represented by Java null - aka Scheme #!null.
> - Testing a value for truth uses the isTrue method above.

[i.e. #!null is false and so is any object of class Boolean that
encapsulates a false value; all other objects are true]

> In addition:
> Option 1:
> - #!null becomes the canonical Scheme false value - i.e. (eq? #f #!null).
> This has some advantages as mentioned above.
> - Hence #!null cannot be recognized as end-of-list in Scheme.
> 
> Option 2:
> - #!null is recognized as false, but not the canonical false value.
> I.e. (not (eq? #f #!null)) but (if #!null 1 0) yields 0 (rather than
> 1 as is currently the case.
> 
> Sub-option 2a:
> - #!null is the canonical end-of-list - i.e. (eq? #!null '()).

On this option, () is false, which is forbidden by R4RS et seqq.

> Sub-option 2b:
> - #!null is handled as end-of-list, but not (eq? #!null '()).

This is the Guile solution:  #!null is both an empty list and false,
but it is not the canonical version of either.

> Sub-option 2c:
> - Don't change-end-of-list handling in Scheme.
> I.e. (null? #!null) remains false.  This causes Lisp-Scheme
> interoperability problems, so it doesn't seem a good long-term solution.

Yes, I think that's problematic.

> I'm not sure which of 2a or 2b would be better.  Both might be
> a pain to implement - lots of changes lots of places.  At least
> as a transition 2b seems easier.

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

This is what I suggested in the first place.

> 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).

-- 
A rabbi whose congregation doesn't want         John Cowan
to drive him out of town isn't a rabbi,         http://www.ccil.org/~cowan
and a rabbi who lets them do it                 address@hidden
isn't a man.    --Jewish saying