I definitely agree here. As Per Bothner continues to write, there are
several ways to handle the fact that #f is not nil in the underlying
scheme core.
Also, I'd like to point out, although I've been following the
discussions from the beginning, I don't recall any explanation of why
this particular modification is so important. Also, this seems to be
one of the modifications most abhored by scheme programmers. Other
modifications (such as case sensitive symbols) and other additions
(such as catch/throw, extra slots on symbols, obarrays, ...) don't
seem to bother schemers nearly as much. In fact, it seems like
schemers are fairly accepting of all the other proposed
modifications/additions, and it's this particular one that they don't
like.
Given that this one point is such a stickler in the scheme community,
I would have thought I would have seen a more detailed defense of it,
but all I recall seeing is the statement that it's needed for the
elisp translation. If there's really any desire to have guile
accepted by scheme programmers, I think a rather complete and
detailed argument should be made as to why #f must be made to be same
as nil.
But, rather than being a "me too" post, I'd like to point out some
other issues regarding making #f the same as nil in the scheme
interpreter.
Basically, it seems to me that setting #f to be nil in the scheme
interpreter violates a fundamental guile design goal.
To support this, here are some quotes from "GNU Extension Language
Plans" by Richard Stallman (dated October 1994):
<snip>
...There's no reason for system designers to try to decide which
language is best. We can instead provide as many languages as
possible, to give each user the widest possible choice. In the GNU
system, I would like to support every language people want to
use--provided someone will implement them.
<snip>
These are the design goals I've decided on concerning extension
languages in the GNU system:
* As far as possible, all GNU packages should support the same
extension languages, so that a user can learn one language (any one of
those we support) and use it in any package--including Emacs.
<snip>
So, it would seem to me that one of the design goals of guile was to
avoid language snobism - that is, to avoid forcing people to program
in any particular language. One of the original goals was that guile
would support a significant sample of other languages. If you wanted
to program in bash shell, you could. If you wanted to program in
elisp, you could. If you wanted to program in scheme, you could. The
way this was intended to be carried out was by running a modified
scheme core, and translating other languages into scheme.
It seems to me that this goal of allowing users the choice of which
language to program in requires being as faithful as possible to each
language. In other words, a TCL programmer using guile should find
his TCL programs to work in guile without modification. To a bash
programmer, guile must behave exactly like bash. In general, guile
must adhere completely and precisely to the standards of each language
it supports, lest programmers whose favorite language is Z be
alienated from guile because guile doesn't support some bizzare
construct which turns out to be beloved by lovers of Z.
I would think that for this reason alone it would be important that
the scheme core of guile to conform precisely to the scheme standard.
Furthermore, why should other languages get fairly faithful
translators, while scheme itself does not? If the TCL programmers
complained that the TCL translation isn't completely true to TCL, I
would think that pains would be taken to modify the translator. By
modifying the scheme core in the face of complaints by scheme
programmers, it seems that the guile designers are falling back to
dictating the language to the programmers. Of course, not nearly to
the extent that this has been done in the past (by other extension
languages), but to a great enough extent to cause unnecessary
frictions between guile developers and scheme programmers and
implementors.
Also, Per Bothner writes:
> 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.
Also, I can't see how doing something of this sort will make the
difference between a simple elisp translator which produces fast code,
and a complex one producing slow code.
After all, so many other things have to be dealt with that I'd expect
one would end up writing a fairly substantial translator anyway. For
example, handling function value vs symbol value vs property value,
handling dynamic binding vs static binding, adding all the elisp text,
buffer, and window primitives, handling the fact that many scheme
primitives will signal errors in cases that the corresponding elisp
primitives return nil (for example in scheme (car ()) and (cdr ())
signal errors, whereas in elisp they return nil), etc. Would handling
#f vs nil as well be so much more difficult, or make the code so much
slower?
-- Dr. Harvey J. Stein Berger Financial Research abel@netvision.net.il