guile-devel
[Top][All Lists]
Advanced

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

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


From: Ludovic Courtès
Subject: Re: Guile Emacs: Elisp nil/t and Guile #nil/#t
Date: Fri, 23 Aug 2013 12:12:55 +0200
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

address@hidden (Taylan Ulrich B.) skribis:

> 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?

Something like that (probably better than binding ‘nil’ and ‘t’
globally.)

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

Yeah, that’s what I would do: patch ‘symbolp’ to DTRT.

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

OK.

I think I’d rather let BT answer the rest of your message (I had been
hoping ey would magically chime in ;-)).

Ludo’.



reply via email to

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