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

[Per Bothner <per@bothner.com>]

On 07/05/2013 11:43 AM, Jamison Hope wrote:
> How will #!null-terminated lists be printed?

I think printing them the same way as LList.Empty-terminated lists:
'(3 4 5 . #!null) print as "(3 4 5)".

> I presume that you mean the Scheme 'list' function here
> [i.e. would construct an LList.Empty-terminated list)], and that the
> similarly-named Common Lisp 'LIST' function would be terminated by
> nil/#!null/#nil.  So, a list created in Lisp code would not
> (necessarily) have exact representational equivalence with one created
> in Scheme code.

Right.  Furthermore, note there is an awkwardness with equal?:
Should: (equal? '(3 4 5) '(3 4 5 . #!null)) ?
I think the answer has to be #f, because (equal? '() #!null) --> #f.

> But Scheme would be able to iterate over Lisp lists correctly, as long
> as it uses null? to check for the end of list (which is the idiomatic
> thing to do anyway):
>
> (define (mylength lst)
>    (if (null? lst)
>        0
>        (+ 1 (mylength (cdr lst)))))

Right.

> Would LList.Empty evaluate as true or false in Lisp code?  Methinks it
> would need to be false, if we want to be able to pass Scheme lists to
> idiomatic Lisp:
>
> (defun mylength (list)
>    (if list
>        (1+ (mylength (rest list)))
>        0))

Probably.  Guile ELisp treats '(), #f, and nil as all equal (though not eq).
So I assume it treats them all as false.

> I would also propose the other obvious optimization, that if the
> compiler can determine that the type of the expression c is
> any-class-other-than-Boolean, then the generated code can just
> be ((c != null) ? e1 : e2).

That seems a worthwhile optimization.

> I would probably go one further and argue that not only should #!null
> be false, so should #!void.

I'm reluctant for a couple of reasons.  Mainly, Kawa treats #!void
as equivalent (though not necessarily eq?) to the result of (values).
I.e. #!void is zero values.  It is not clear that zero values
should be false.  I think a zero-length tuple is true.

There is also the pragmatic issue in Kawa in that multiple values
are represented using the gnu.mapping.Values, so you have to check
Values#isEmpty().  Also, Values instances may sometimes be mutable.
For example there is the ValueStack class, which extends Values.
This is admittedly not very clean, but I think that is an
issue for another day.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/