[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: |
Sun, 04 Aug 2013 02:13:45 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) |
Neil Jerram <address@hidden> writes:
> Solution for what problem?
A from-scratch explanation, just so I'm sure I'm clear:
For different languages running on Guile to integrate seamlessly, we
want them to share as many data-types as possible. E.g. it would be
inacceptable if a JavaScript function returned `true' and a Scheme
procedure receiving this value didn't just see it as #t but instead as
some weird `js-true' value which it needs to handle specially; we want
both JS's true and Scheme's #t to be the same internal value on the
Guile platform.
We use SCM_BOOL_T for said true value. And for Elisp integration we
invented SCM_ELISP_NIL, which can be used both in place of the global
false value, SCM_BOOL_F, and as the null (aka end-of-list) value for
Lispy languages, SCM_EOL.
Problem is, Elisp isn't really satisfied with *either* of those. It
expects that its true value and its nil (false and null) value are both
also *symbols*, as if its abuse of nil for two purposes weren't enough.
So, how do we implement a `symbolp', `symbol-value', `symbol-function',
etc. which all work with SCM_BOOL_T and SCM_ELISP_NIL? (Also, reading
those symbols even in quoted form must yield the same objects, so we
need to make Elisp's `intern' and `read' act accordingly.)