Re: proposed changes to handling of false and end-of-list

[Alex Mitchell <lexaay at gmail dot com>]

Hi Per,

This seems like a worthwhile change to me. I know I've had to explicitly handle Java null in a few places in HypeDyn, so having null? behave consistently would be helpful. I'm not sure if the change to have Java null considered false will cause me any problems but I think it's worth the trouble for the benefits the resulting consistency will bring.

Alex

On Jun 29, 2013, at 2:47 PM, Per Bothner <per@bothner.com> wrote:

> A discussion on the kawa-commonlisp-dev list has suggested
> we might want to consider some changes in Kawa's handling
> of null, false, and the empty list.
> 
> The high-level summary:
> * Java null (#!null in Scheme syntax) would be considered false
> (rather than true).  I.e. in an expression (if c e1 e2) if c
> evaluates to Java null *or* a java.lang.Boolean such that
> c.booleanValue()==false, then e2 is evaluated; otherwise e1 is evaluated.
> * The function null? would return true both of the empty list '()
> (the value of LList.Empty) and Java null.  A linked-list may be
> terminated by either '() (i.e. LList.Empty) or Java null.  Lists
> constructed using the Scheme reader or the 'list' function would
> by terminated by LList.Empty as now.
> * Common Lisp, Emacs Lisp, and similar languages (which we will
> call "Lisp") would represent nil using Java null (rather than as
> now LList.Empty).  Lisp would recognize the same values as "true"
> as Scheme does; likewise for end-of-list.
> * This change would have some negative performance impact, but
> hopefully not much.
> 
> The biggest motivation for this change is improved compatibility
> with Lisp.  This is similar to the solution adopted by Guile:
> http://www.gnu.org/software/guile/manual/html_node/Nil.html
> (We might consider implementing #nil as a synonym for #!null,
> for Guile compatibility.)
> 
> However, even if you don't care about Lisp, it probably seems
> reasonable to consider Java null "false" rather than "true".
> Allowing #!null as the end of a list may be less valuable,
> but it does seem preferable for (null? #!null) to be true.
> 
> There are also some anomalies it would be nice to fix.
> Java (and Kawa) allow you to create fresh java.lang.Boolean
> objects:
>    (define-constant b1 (java.lang.Boolean #f))
> However, this object is considered true, not false:
>    (if b1 1 0) ==> 1 ; not (as one might expect) 0
> 
> Currently (if c e1 e2) is compiled to the equivalent of:
>    (c != Boolean.FALSE ? e1 : e2)
> The proposal would change this to:
>    (isTrue(c) ? e1 : e2)
> where isTrue is this library method:
> 
> public static final boolean isTrue(Object value) {
>   return value != null
>      && (! (value instanceof Boolean)
>          || ((Boolean) value).booleanValue()));
> }
> 
> This is obviously slower; however, it is not as bad as it seems.
> If the compiler determines that the type of the expression c
> is 'boolean', then the generated code is the same as Java:
>    (c ? e1 : e2)
> The Kawa type 'boolean' is the same as Java - i.e. a primitive
> (non-object) type.
> 
> For example:
>   (if (> x y) e1 e2)
> compiles to:
>   (NumberCompare.$Gr(x, y) ? e1 : e2)
> because NumberCompare.$Gr has return-type boolean.
> The same is true of other predicates, comparisons,
> and types tests.  (Or at least it is supposed to be -
> bugs may exist.)
> 
> Finally, you can always optimize by hand.  If you want
> the old behavior (and generated code) you can always do:
>   (if (not (eq? c #f)) e1 e2)
> Since both 'not' and 'eq?' are optimized this generates
> the same code as (if c e1 e2) now does.
> 
> Comments?  Does this seem like a worthwhile change?
> Of course this is a not a simple one-line change, so
> it would take a while (and some intermediate steps)
> to implement fully.
> -- 
>    --Per Bothner
> per@bothner.com   http://per.bothner.com/