Re: Elisp development news

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> Now here's Jim's proposal and my comments on it...
> 
>   From: Jim Blandy (address@hidden)
>
> [...]
>
>   None of the obvious compromises work nicely. Modifying either
>   language to match the other breaks existing code in ways that are
>   impossible to fix mechanically. Making Emacs Lisp's nil identical to
>   either of Scheme's #f or '() will cause misinterpretations when Scheme
>   receives either Boolean values or lists from Emacs Lisp.
> 
> How?  Jim isn't clear about these misinterpretations.
> 
> Given <the set of objects that Elisp code treats as false>, and an
> Elisp function that may return any of these to indicate false, a
> Scheme function examining this return code would have to check for all
> possible Elisp false values.  I don't see how this interacts with the
> question of whether nil can be identical to either #f or '().

I think Jim refers to the goal to be `nearly transparent': there might
be cases where explicit conversion between Scheme and Elisp data
structures need to take place, but they should be very sparse and for
the unusual situation.

When nil is equated with one of '() or #f, only the context determines
whether it should be treated as false or as null in Scheme.  You would
have to know in what context you are to use the right predicate.  It
is easy to write Scheme that knows the context, but if we can arrange
things so that one can write code that works regardless of context, it
would be better.

For example, suppose nil is the same as #f.  This means that Elisp
lists are #f-terminated and you can't pass it to functions that expect
Scheme lists.  This would prevent you from using (ice-9 common-list),
say.

If nil would be the same as '(), Elisp lists and Scheme lists would be
the same, but Elisp would use '() to indicate false.  It would be
unnatural to use predicates written in Elisp with Scheme functions.

In general, we would need to closely track what values have been
produced by Elisp, and with what meaning.  Doing this statically,
without support from the system, is hard and will ultimately fail.
Doing it dynamically is equivalent to not equating nil with either #f
or '().

>   We want list-valued Scheme and Emacs Lisp functions to interoperate.
> 
> Yes, but ...
> 
>   So Scheme must be able to return '() to Emacs Lisp, and have Emacs
>   Lisp recognize it as the empty list. Emacs Lisp must be able to
>   return nil to Scheme, and have Scheme recognize it as the empty list.
> 
> ... not quite.
> 
> For any value X that language A passes to language B, the requirement
> is that B understands what A means by X, to the extent possible given
> B's own linguistic limitations.

Right.  But this understanding should persevere thru layers of
ignorant code and should be extractable from data structures.

This is possible to do statically, but will look unnatural and
needlessly hard for a dynamically typed language, in my opinion.

> Where null-like values are concerned,
> 
> - When A is Elisp and B is Scheme, "what A means by X" can only mean
>   whether X is false/empty in the Elisp sense.  If the concept of
>   Elisp false/empty maps to more than one distinguishable value in
>   Scheme, note that
> 
>   - it is possible and straightforward to write a Scheme predicate
>     `elisp-false/empty?' that returns #t if its argument is any of
>     those values
> 
>   - it doesn't make sense for the Scheme side to try to draw any
>     conclusion by examining which of those values is the one actually
>     returned, since the distinction was not observable in Elisp.

But Scheme might want to `do the right thing' without knowing that the
value came from Elisp, and in what context.  It might want to do this
because tracking this information might be too hard.

> My statements are weaker than Jim's.  For example, his
> 
>   "have Scheme recognize it as the empty list"
> 
> becomes my
> 
>   "have Scheme tell the difference between a non-empty list and a
>    false/empty value".
> 
> But I think that my statements are all that is necessary in practice.

Maybe, but I don't think it Jim's proposal is difficult to implement
or necessarily inefficient.

> The crucial consequence of this weakening is that the set of Guile
> values that describe end-of-list in Elisp do not all have to satisfy
> (null? x) in Scheme, and the set of Guile values that describe false
> in Elisp do not all have to satisfy (not x) in Scheme.
> 
> This opens the door for proposing that `nil' be made identical to #f
> and Elisp's '() the same as Scheme's '().

But in Elisp nil and '() are the same.  You can rig Elisp `eq' to
recognize this, but it is legal in Elisp to terminate lists with '()
or nil, so I don't think it makes sense to have Eliusp '() and Elisp
nil not be equal.  They would have to be treated identically in all
contexts.

>   I don't see any harm in telling Emacs Lisp that #f is an empty list.
>   That merely equates two objects that Emacs Lisp never distinguished
>   anyway.
> 
> I'm not clear what Jim means here.  If that (if (null X) "yes" "no")
> => "yes", where X is the Scheme #f value, fine.

Yes, that's how I understand it as well.


So, I think Jim's proposal gives us the same things as your proposal,
and more.  What is the advantage of your proposal over Jim's?