[Top][All Lists]

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

Re: Emacs Lisp's future

From: Daniel Colascione
Subject: Re: Emacs Lisp's future
Date: Wed, 17 Sep 2014 15:42:57 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

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

I'd be happy to use the lower-level portions of Guile for compiling
elisp more efficiently, but I'm adamantly against trying to support both
Scheme and elisp simultaneously. All in all, I think the effort would be
better spent elsewhere.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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