the viability of translators, and Guile itself

[Jim Blandy <jimb@red-bean.com>]

Someone (who didn't seem to want to post to the list) wrote me
recently asking some good, hard questions about whether translators
are a good idea.  I felt that the answer should go here.

The writer asks about the viability of Guile as a replacement for
Emacs Lisp.  There are several aspects to this question.

Is Scheme really a better language than Emacs Lisp?  Having pretty
extensive experience with both, I personally prefer Scheme to Emacs
Lisp, hands down.  I think lexical scoping is a major win, for
example.  But I also think people frequently exaggerate the importance
of the details of the language.  Anything with a decent type system
(which is where languages like Tcl and Perl really botch things, in my
opinion) and an implementable execution model would do as well.

Is Scheme harder to learn than Emacs Lisp?  I don't think so.  I think
the problems we're seeing accrue to a lack of documentation and a lack
of good examples.  I think simply writing a decent introduction to
Scheme --- shorter than a full-length textbook, with pragmatic
examples --- will make a huge difference here.

Is Guile really a better implementation than Emacs Lisp?  I believe
conservative GC is the only reasonable way to mix C and Scheme.
Beyond that, I think Guile is way crufty.  I don't think it's fair to
put down Aubrey's code --- I think he has different goals, which he
achieves with great success.  That said, I find it impenetrable.  And
there's plenty of other impenetrable code which lacks any redeeming
qualities whatsoever.

However, one of the goals of Guile is to be a focal point for the
fragmented Scheme community.  Rather than having dozens of hackers
invest their time in dozens of Scheme implementations, if we can have
one which people *believe* will become ubiquitous, that's a major
service to the community.  That's why the endorsement of the FSF and
GNOME are so important to Guile.

From that point of view, the immediate quality of the implementation
isn't so important, as long as there's a consensus to work together on
improving it.  That consensus doesn't exist now, but I think we can
build it.  I believe there exists a clear path, a set of specific
changes, that we can follow to make Guile a more attractive extension
language than Tcl/Tk or Python.  That path involves real
documentation, a source-level debugger, Guile/GTK, GOOPS, generational
GC, and internationalization.  These are all projects in progress now,
or soon to be in progress.  (Stallman says he has money to hire
someone to rewrite the Guile manual.)


But, back to translators: if they're such a great idea, how come they
don't exist?  This is a very embarrassing question, especially since
I'm advertising them as a feature on the Guile web page.

I don't think they're really that hard to do.  We're missing two pieces:

- A standard interface for connecting a translator to Guile.  It's
  simply not clear how to hook up a translator nicely, so that the
  module system and the REPL all understand it properly.
- A single readable example.  CTAX is built on some highly
  idiosyncratic modules; if someone simply reimplemented it using flex
  and bison, that would give others a model to emulate.

Is it always possible to implement a translated language's semantics
correctly?  Certainly.  You can always write an interpreter for any
language in any other language.  The real challenge lies in sharing
data between modules written in different languages.  That's a task to
be approached very carefully.