*** NOTE: This article is being posted by Bryan O'Sullivan <bos@serpentine.com>,
because Jim Blandy doesn't read news. If you want Jim to read
your response, mail him directly.
[I don't read netnews at all, but a friend told me that there was some
confusion about Guile, its goals, and its current status. I agreed it
might be helpful for me to post an explanation.]
Regarding the #f/() distinction: Guile is intended to implement the
language described by R4RS, which doesn't require #f and () to be
distinct. However, the spirit of the report seems to suggest that
they should be distinct; the IEEE standard, based on R4RS, requires
this; and the advance news of R5RS says it will require #f and () to
be distinct. So, although releases of Guile before the FSF's 1.0
release did confound #f and (), Guile 1.0 does not, and subsequent
releases will not.
One of Guile's major goals is to support multiple extension languages,
by compiling them all to Scheme. That way, the author of an
extensible application would not have to commit all her users to the
same extension language; each user could choose for himself. One of
the first languages we hope to support is Emacs Lisp, because we
eventually plan to replace Emacs's lisp interpreter with Guile, and we
must support the existing body of Emacs Lisp code.
Emacs Lisp, like many (most?) older lisps, uses the same object to
represent the empty list and the false value. The data worlds of
Scheme and Emacs Lisp are tantalizingly similar; the #f/() issue is
pretty much the only significant obstacle to the completely
transparent exchange of data between Emacs Lisp and Scheme code. So,
the temptation to equate the two was rather strong, especially given
R4RS's tolerant stance on the question.
However, in the face of strong objections from the Scheme community,
we developed another approach which, although not perfect, seemed to
allow Emacs Lisp and Scheme to share data pretty well, while perfectly
preserving the semantics of each language when used alone. Once we
were satisfied that this approach would work, we changed Guile Scheme
to once again distinguish #f and ().
There has never been any plan to change Guile Scheme to use dynamic
scope. Come on. However, the proposed Emacs Lisp->Scheme translator
would certainly need to preserve Emacs Lisp's semantics, meaning that
we would need to extend the target language with efficient support for
Emacs Lisp's primary scoping discipline. This does not imply that we
would change the semantics of Scheme's LAMBDA.
(Someone's post characterized the FSF as "the big boys", or some such
phrase, lumbering onto the playing field and settling the #f/()
question by fiat. I almost died laughing. Sure, the FSF has
influence, but only because we (occasionally) write code instead of
talking. Anyone else who wants their share of power can do the same
--- witness the respect Olin Shivers and Brian Carlstrom have earned
from the community through their work on SCSH. And the story isn't
even true anyway --- we capitulated.)
Alan Bawden makes some valid criticisms of the Guile 1.0 distribution.
Yes, the documentation is out of date, and otherwise inaccurate. At
the time of the release, I had an externally-imposed deadline, and had
to choose between inaccurate documentation, or none at all. I now
think I made the wrong choice in including those docs in Guile 1.0.
The build process in the Guile 1.0 distribution is a horrific pile of
dog hair and rancid fettucine, despite the sincere efforts of some
talented people to make it work out. I've recently separated out the
interpreter from the rest of the package, in an attempt to address
exactly this problem. If you'd like to try out the slimmed-down
Guile, please retrieve:
ftp://ftp.cyclic.com/pub/guile/guile-core-snap.tar.gz
Please understand, this is a nightly snapshot of my working sources,
and will contain changes which have not been widely tested.
|