Re: %nil once again

[Neil Jerram]

Clinton Ebadi <address@hidden> writes:

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

Yes.  It's just the Elisp->Scheme data translation point again,
though, as you say:

> 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,

Right.  Elisp code that generates a boolean result, for use by Scheme,
would need to have that result translated from () to #f.  But then
what about Elisp code that generates a vector of boolean results, or
an alist of vectors of boolean results...?

> and any
> Scheme calling elisp should know this and use null? to check for a false
> return value.

The ultimate point of multiple language support is that an application
user can write a hook or configuration tweak in whichever language
they feel comfortable with.  The driving C or Scheme code that calls
out to that hook or tweak needs to work regardless of the user's
language choice.

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

I don't like that at all!

In my view, the only reasonable alternative solution above is the one
that would work by translating data passing between Elisp and Scheme.
The theoretical argument against that is that such translation could
be arbitrarily complex, and so have an unbounded performance cost, but
in practice I imagine that would almost never be the case.  Also there
is the point that languages other than Elisp will _require_ data
translation, and why should we make Elisp a special case?  Hence I
wouldn't rule out the possibility of switching to this design in
future; and then we could, as you say, make nil==() and remove most
elisp special cases from the libguile core.

Regards,
        Neil