[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile Emacs: Elisp nil/t and Guile #nil/#t
From: |
Taylan Ulrich B. |
Subject: |
Re: Guile Emacs: Elisp nil/t and Guile #nil/#t |
Date: |
Mon, 19 Aug 2013 13:41:34 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) |
address@hidden (Ludovic Courtès) writes:
> address@hidden (Taylan Ulrich B.) skribis:
>
>> It occurred to me that nil and t are basically just symbols in Elisp,
>> just with some magical properties. Like any symbol, they respond to
>> symbolp, have a plist, value and symbol slot (although the value slot
>> is immutable), etc. They're self-quoting, so 'nil and 't also just
>> return nil and t. Nasty stuff.
>
> Perhaps I’m overlooking something.
>
> To me, it looks like it’s just a matter of binding ‘t’ to #t and ‘nil’
> to #nil in the elisp run-time. This is currently not the case:
>
> elisp@(guile-user)> nil
> $3 = #nil
> elisp@(guile-user)> 'nil
> $4 = nil
> elisp@(guile-user)> t
> $5 = #t
> elisp@(guile-user)> 't
> $6 = t
You mean we should make the Elisp reader return #nil and #t for the
symbols nil and t even when quoted? The problem with that is that this
would simply make them not be symbols:
(symbolp nil) => nil
(symbolp 'nil) => nil
(symbolp t) => nil
(symbolp 't) => nil
(symbol-value 'nil) => error
(symbol-function 'nil) => error
...
That is, unless we make changes to all the relevant functions that work
on symbols, and make them handle #nil and #t specially. That is more or
less what my patches do in the Emacs Elisp implementation (by altering
some low-level functions that all others use to work with symbols).
By the way, if I got it right, we intend to scrap most of the Emacs
Elisp implementation once Guile's is done. That would mean my patches
are in the wrong place, although I suppose the strategy can be ported
over. That might however add some complexity to the C API, most notably
having both `scm_symbol_p' and some `elisp_symbol_p', forcing the user
to be constantly conscious about the difference between Scheme and Elisp
symbols, and then there's the question whether all Scheme procedures
other than `symbol?' should share the same low-level functions from the
C API with their Elisp equivalents, and thus also work with #nil and #t
when used from Scheme (e.g. `(symbol->string #t) => "t"' in Scheme), or
also have separate Scheme and Elisp variants in the C API such that the
Scheme world is not further confused by the issue.
Another question that raises is how the symbols `nil' and `t', when
generated by Scheme code, should behave in Elisp and the C API. I guess
we would just have them look like uninterned symbols in Elisp? As far
as my imagination goes at the moment that seems to be the cleanest
solution.
Taylan