Part of the problem is that we are not being clear about what
kind of compatibility we are talking about. Clearly, source
level compatibility is out of the question: Emacs Lisp and
Scheme are too different for one to be a superset of the other.
What we want is for code written in the two languages to
co-exist and interoperate at run-time. There are a number of
ways we can achieve this, without having to change the semantics
of Scheme programs.
One solution has been proposed: the Emacs Lisp versions of eq,
null, if etc treat #f and '() as synonyms. I think this approach
has the best "compatibility". However, it does break the
"tradition" that eq is a trivial (pointer) compare.
There are solutions that preserve the traditional "primitiveness"
of eq. You can do that by having the Emacs Lisp primitives
just us the '() value and ignore the Scheme #f false.
You need separate Scheme abd Emacs Lisp versions of the various
predicates: The Scheme version returns #t and #f, while the
ELisp version returns 't and '(). This is reasonable enough,
since the names are different anyway.
This solution does have some compatibility problems (a Scheme
function that returns a boolean cannot be used directly as a
ELisp function thta returns a boolean), so hacking eq/null/if/etc
is probably better (safer but slower)..
Note that saying that the Scheme values #t and '() must
be the same because Emacs Lisp does not distinguish them
is basically the same as saying that the character #\A
must be the same as the integer 65 because Emacs Lisp
does not distinguish them. What is the rationale for
insisting on the former but not the latter?
--Per Bothner
Cygnus Support bothner@cygnus.com