Re: JACAL, scm

[Tom Lord]

      rlb asks:

       What are the requirements of a "correct" solution?
       For example: 

           [paraphrased: 

            Should elisp and Guile interoperate smoothly?
            Can't ()/#f be solved with a startup-time option?
            Will future guile-based emacs still run Emacs Lisp?
           ]


I agree that that is a good series of questions.

I can offer some "historical" answers, based on decisions made in the
early days of the project.  I think these historical answers are good
ones -- they ought to still be in effect.  

There is some context behind these historic answers: the effort to
build an extension language for the GNU project.  Guile wasn't
established in a vacuum.  It isn't just an isolated project to build a
nice Scheme implementation.  Rather, Guile is part of a long term
strategy for building a coherently designed set of software tools:
tools that all work well with one another.

When you're trying to make a large system coherent, a central
authority is often a Good Thing -- not always, but often.  I think it
was probably RMS who first ordered that #f and () be the same.  I
don't specifically recall my reaction but I was probably slightly
disappointed at the time.  Like a lot of people, I once thought that
(not (eq?  '() #f)) "seems cleaner" for some vague reason.  But in
retrospect, having explored the issues more, having written a lot more
Scheme code, and having thought about the relation betwen Guile,
Scheme, Lisp, Emacs Lisp, and GNU -- the original decision to make '()
and #f the same was very much the right one.

Lisp compatability was the reason for making '() and #f the same in
Guile.  Not just Emacs lisp -- but lisp generally.  We didn't talk
much, back then, about Common Lisp compatability but we ought to have.
It was a goal to be able to easily mingle Scheme and Lisp (including
Emacs Lisp) code and data.  There is no way to do that unless '() and
#f are the same.

It was a goal to reach a version of GNU Emacs that supported both
elisp and Guile.  To the largest extent practical, elisp was to be
just another syntax for programming Guile, optimized for different
needs.  Mixing elisp and Scheme code in a single process was
considered important.  Avoiding awkwardness when calling between the
two languages was considered important.

Within GNU Emacs, there are at least four good reasons for retaining
elisp: (1) there's a lot of elisp code; (2) there are many elisp
programmers; (3) although elisp has some weird semantics (especially
dynamic scope), those semantics work out nicely for programming
interactive commands; (4) GNU Emacs is a large, complicated program --
we hoped to adapt it to Guile without having to make sweeping changes
to the Emacs source code.

We never considered implementing an initialization switch that would
let Guile run in two separate modes (one with (eq? '() #f), one not).
I think we would have rejected that idea.  While a feature like that
could kill a narrowly focused debate on the mailing list, it would
make a mess when it came time to deploy Guile as the GNU extension
language -- some programs using one mode; others the other mode.
Guile is, in part, supposed to be glue; having two, incompatible types
of glue would be awkward.

It was a fairly early goal to be able to run very picky R5RS code that
relied on () being distinct and true.  Being able to freely mingle
that kind of R5RS code with other Guile code was *not* considered
terribly important.  There wasn't much finicky R5RS code around (and
there still isn't).  Schemers writing portable code still had the
habit of not relying on ()/#f being either the same or different.  We
had no trouble running slib -- and took that as good evidence that we
were in fine shape with respect to running portable Scheme code.

I vaguely recall thinking that a segregated R5RS compatabile top-level
environment might be useful for playing with toy Scheme programs from
within an application built using Guile. I vaguely recall doing enough
design work to make sure we could build an R5RS environment in order
to quell some flame wars on the mailing list. I don't recall that we
had any more serious reason than that to want a strict R5RS
environment.

When we thought about how to support an optional R5RS environment,
the idea came up of having three values:

        nil     - used by most of Guile as both '() and #f
        eol     - used by an R5RS top-level as '()
        false   - used by an R5RS top-level as #f

I think it was Bushnell who came up with that.  It's a cute hack for
making built-ins a little bit more general.  It wasn't originally our
intention to use "eol" and "false" in any serious way in Guile.  In
retrospect, I think we got too caught up in the cuteness of this hack
and its rhetorical usefulness.  We might have been better off sticking
to our guns and postponing work on R5RS indefinitely.

After Blandy took over maintainership, for some reason, he promoted
that minor design plan to a central feature.  He demoted the goal of
lisp compatability without explanation.  Go figure.

I was too tired to argue against that change at the time: it seemed
characteristic of a lot of dubious changes that were being made.
Stuff was being ripped apart left and right and the goal of creating a
coherent design seemed doomed.

In retrospect -- it might have been more responsible of me to put up a
fight at that time to keep the project on track.  There's a humorous
message in the archives from Gallassi about "breaking up" the
Stallman/Lord/Jaffer "triumvirate" which is probably relevant here.

-t