emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp's future


From: David Kastrup
Subject: Re: Emacs Lisp's future
Date: Thu, 18 Sep 2014 05:17:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Daniel Colascione <address@hidden> writes:

> On 09/17/2014 01:11 PM, Taylan Ulrich Bayirli/Kammer wrote:
>> Actually, this is just a special-case of the first point, regarding the
>> applicable data type (libguile procedures) being handled in a uniform
>> way without extra overhead in the case it "comes from the other
>> language."
>> 
>>>> - The handling of nil vs. Scheme #f and '() is admittedly a wart, but
>>>>   will probably remain hidden, not causing issues in code you write.
>>>
>>> I have problems seeing how it can remain hidden.
>> 
>> Please mention any concrete problematic cases you can think up.
>
> Imagine the round trip a value might take: #f in Scheme to nil in elisp
> to something back in Scheme.

It doesn't.

See
<URL:https://www.gnu.org/software/guile/manual/html_node/Nil.html#Equality-2>.
I quote:

    However, in Elisp, '(), #f, and nil are all equal (though not eq).

    (defvar f (make-scheme-false))
    (defvar eol (make-scheme-null))
    (eq f eol) ⇒ nil
    (eq nil eol) ⇒ nil
    (eq nil f) ⇒ nil
    (equal f eol) ⇒ t
    (equal nil eol) ⇒ t
    (equal nil f) ⇒ t

> If you alias #f, (), and nil together from an elisp perspective, then
> when you need to differentiate these values, you can't, because you've
> just thrown away the information you'd need to do that. You can't make
> the object's true identity a hidden property of the value either,
> because that breaks perfectly valid code like this:
>
>   (defun identity-x (x) (if (eq x nil) nil x))

(eq x nil) is just something you are not expected to do if a list or
condition may come from a Scheme function.  Of course, that includes
using x for eq-based hashing.

The GUILE manual (in the above-mentioned section) states with audacity

    Fortunately, using not and null? is in good style, so all
    well-written standard Scheme programs are correct, in Guile Scheme.

Of course, that glosses over the fact that the end of a list may well be
implicitly checked for by using sentinels and other quite legitimate
programming practices.

For example, two proper lists generally have a common tail, even if that
tail is only '(), and finding that tail is done by trimming the longer
list to the size of the shorter one and then cdr-ing the remaining lists
in synch until arriving at a matching value.

Using "equal" for that comparison is not an option, and using "eq" is no
longer guaranteed to terminate without error.  The solution is to
declare the algorithm not well-written.

Cynicism aside, it will be advisable not to venture into Scheme too much
in order to avoid having the Scheme end-of-list and the Scheme #f turn
up at all.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]