Re: %nil once again

[Clinton Ebadi <clinton@unknownlamer.org>]

Daniel Kraft <d@domob.eu> writes:

> Hi,
>
> I think I got the test-suite as well as a basic macro implementation
> (the compiler framework is really cool, that was fairly easy to do);
> recursive macros do not yet work, but otherwise it looks fine.
>
> However, I want to tackle quasi-quotes (besides others) now; and in
> Elisp %nil is not only #f of Scheme but also the end-of-list marker (I
> guess that's why simply using Scheme's #f for %nil does not work).

[...]

> It would be cool to teach Guile somehow to treat %nil as the
> "standard" end-of-list value, such that both of these queries would
> optimally return true.  At least, is there some way to construct lists
> terminated by %nil using something like the list primitive?  Other
> things needed would be for instance terminating rest-arguments by %nil
> rather than '() and the like.

Why not eliminate %nil/#nil and replace it with ... '(). This would
allow elisp to reuse all (or at least most) of the Scheme list functions
without having to muddy Scheme semantics with special #f/#nil handling,
but would require a very tiny elisp specific truth predicate. Since
everything should be compiled into an IL instead of Scheme this should
be straightforward. This would have the rather nice advantage of
removing all special elisp support code from libguile itself (thus
cleaning up libguile a bit *and* making the elisp translator a much
better example for other language translators since every language can't
expect to have special support from libguile).

If the Scheme value #f leaked into an elisp lisp/vector/etc. then it
should *not* be treated as false to elisp because it is *not* an elisp
false value; likewise if '() leaks back into data used by Scheme there
is no particular reason to treat that as false and not end of list.

This has the slight downside that calling between elisp and Scheme may
not be so natural. Any elisp that would call Scheme must know it is
calling Scheme (or simply not-elisp) and that it ought to generate
Scheme false objects if it is calling a predicate of some sort, and any
Scheme calling elisp should know this and use null? to check for a false
return value. The only downside I can see to this is that if code were
to be ported from elisp to Scheme there would now be code that assumed a
'() return as false when #f would be false, but this could be fixed
using a predicate like elisp-false? (or null-or-false? or
... something).

Having multiple distinct false values is almost as bad as punning false
and end of list and so I think the few disadvantages do not outweigh the
advantages.

-- 
Leebert: You don't listen to music.
Leebert: You listen to the audio equivalent of /dev/urandom