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

[Taylan Ulrich B.]

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