PROPOSED PROPERTIES
(0) ONLY the code actually interfacing Scheme and Emacs Lisp bears the
cost of the semantic incompatibility of boolean values. I.e., pure
Scheme and pure Emacs Lisp run as efficiently as possible. In
particular, Scheme `eq?' and Emacs Lisp `eq' are single pointer
comparisons; similar efficiency for Scheme `if', `and', `or', and
Emacs Lisp `if', `and', `or'.
(1) The cost is VISIBLE in the affected code.
(2) Scheme distinguishes '() and #f. The #f is the ONLY false value,
`() is the ONLY empty list (in the sense of single pointer comparison
implementation of `eq?'). Thus, (tentative) R5RS Scheme runs under
Guile (with the efficiency promise of `eq?' fulfilled).
(3) Emacs Lisp considers the #f a foreign object and uses '() as its
ONLY boolean false.
(4) Emacs Lisp code runs under Guile.
(5) Expressions like `(cons foo #f)' have IDENTICAL semantics in
Scheme and in Emacs Lisp. That is, no subtle bugs this way.
PROPOSED SOLUTION
Guile Emacs Lisp
-------------------------------------------------------------------
#t t
#f an (currently nonexistent) object (not `nil'!)
'() nil
'() (not t)
'() '()
'() ()
elisp-if if
elisp-and and
elisp-or or
etc.
-------------------------------------------------------------------
Note: I guess the `()' construct (without the quote) is illegal in
Scheme as it would be considered an erroneous function application.
Is this correct interpretation?
INTERFACE MACROS (provided in both Emacs Lisp and Scheme):
falsify identity, except that '() yields #f
emptify identity, except that #f yields '()
Scheme and Emacs Lisp do not share boolean value semantics --- this is
a fact of life. Thus, the above macros provide appropriate "wrappers"
for the case that Scheme part and Emacs Lisp part wish to
exchange/translate a boolean value. I think this can easily work on
both Scheme and C levels.
DATA STRUCTURE SHARING
Transparent. Object #f is NOT recognized as nil by Emacs Lisp.
INTERACTION BETWEEN SCHEME AND EMACS LISP LIST OPERATIONS (functions
and/or special forms)
Transparent.
INTERACTION BETWEEN SCHEME AND EMACS LISP LOGICAL OPERATIONS
(functions and/or special forms)
Use explicit conversions via `emptify' and `falsify'.
Examples:
Assume `foo' be a list and `bar' be a pair. Then:
(and (null? foo)
(falsify (lisp-car bar))
is equivalent to
(falsify
(lisp-and foo
(lisp-car bar)))
is equivalent to
(and (null? foo)
(null? (car bar)))
is equivalent to
(falsify
(lisp-and (emptify (null? foo))
(lisp-car bar)))
Q: Now what is wrong with this one?
I understand that high transparency of the Scheme <-> Emacs Lisp
interface may overweigh low-level efficiency considerations (besides,
Guile is intended to be an interpreted extension language anyway) but
the complexity of Guile specification is the important issue as
well...
Our life is frittered away be detail... Simplify...,
simplify, simplify. (David Henry Thoreau).
If anything at all, perfection is finally attained, not when
there is no longer anything to add, but when there is no
longer anything to take away. (Antoine de Saint-Exupery)
Make everything as simple as possible, but no simpler.
(Albert Einstein)
Does Guile indeed deserve a _Trinity_ of empty-list/false values? Is
it not "simpler than possible"? Imagine the length of the manual
section explaining and rationalizing a specific solution to this
problem. Imagine puzzled looks on faces of novices.
Imagine another revolutionary period in the distant future when Emacs
is fully schemized (schemed? guillified? gullible? guilted?) and Emacs
Lisp long gone: I think the posterity would wish to get rid of the
Trinity, desiring (distinct) pure #f and pure '() (provided this is
where Scheme is aiming).
I am NOT attempting to advertise this approach (already discussed here
in one form or another) as an unambiguously `better' solution than the
Jim Blandy's proposal --- I just wish to understand the relative
(de)merits of the competing and/or contradictory requirements and am
curious to see for myself what the costs and benefits of alternatives
really are.
I will appreciate your comments and your critique.
Thanks.
-- Petr Adamek