Re: Guile Emacs: Elisp nil/t and Guile #nil/#t

[Taylan Ulrich B.]

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