RE: What's so cool about Scheme?

["Anton van Straaten" <address@hidden>]

Steve Dekorte wrote:
> If you want to learn about implementing a language in Scheme (or
> "why Scheme is cool"), you might find this book helpful. If your
> interested in implementing a language in C/C++, you might be
> disappointed. It's an expensive book, so you might want to check
> it out before ordering it sight-unseen from Amazon.

I'd say it's not so much a book about implementing languages, as
*understanding* language implementations, which includes understanding the
abstractions that make up language implementations.  For these purpose,
C/C++ is a distraction.

Describing it as "a book about how to implement a Scheme in Scheme" rather
misses the point.  One point being missed is the importance (or lack
thereof) of typical language syntaxes.  Think of Scheme for this purpose as
a simple and consistent way of representing abstract syntax trees for any
language.  That's why it has little obvious "syntax" other than parentheses,
and how you can do things like express XML natively in Scheme (see e.g.
SXML).

When you see a snippet of code in EOPL that's written in one of the book's
own languages, don't think of it as Scheme - think of it as the essential
semantic core of a language which could have any of a variety of surface
syntaxes.  The EOPL languages already have some syntax, provided by macros,
but this also can be thought of as a kind of core/internal syntax.  You
could take any of the EOPL languages and use a lexer and parser generator to
quite easily create a more traditional syntactic surface, which maps to the
exact code in the EOPL book.  What you'd end up with would look as much like
any traditional language as you want it to (although your semantic core
would be better designed).  So for the purposes of EOPL, C/C++ and a
language's surface syntax are both distractions.

What I'm describing might sound impractical to the uninitiated - maybe you
wouldn't want to implement a "real" language on top of a Scheme-like core.
The only problem with this assumption is it's completely wrong: there are
any number of real languages that do exactly this.  Every functional
language that can be compiled to a bytecode, including Haskell and various
ML varieties, compiles to a bytecode that bears a strong resemblance to
Scheme.

Why is that?  It's because Scheme is an expression of some core mathematical
ideas about computation: a relatively minimal set of features that provides
a complete computational framework.  If you're implementing a functional
language, when you get down to its core, below the syntax and the derived
semantic features, you're likely to end up with something that looks a heck
of a lot like a Scheme core.

EOPL, then, is a book about how to implement a number of language cores with
different characteristics, expressed in terms of a more basic language which
lacks those features.  This is the essence of language development.  It's
not everything there is to know about it, but it's an important part.  It's
not a book about compiling to native code or to C.

One question would be whether you'd want to implement something other than a
functional language using an approach like this.  That, in essence, is
Steve's objection: he's not thinking about implementing functional
languages, so perhaps he thinks none of this has any relevance for what he
has in mind.  That, too, is questionable.  But even if you don't choose to
implement your next language in Scheme or on top of a Scheme-like functional
core, there's still a lot that a book like EOPL can teach about designing
and implementing languages, if you can get past a few prejudices.

> If that means more on implementing an OO stuff in Scheme, then I'm
> not sure how helpful that is to a language implementor is unless
> you consider it practical to implement one scripting language in
> another(sort of like implementing Python in Perl)

If Scheme is a scripting language, it's the fastest one on the planet, by a
wide margin.  There's a big difference between Scheme and Python/Perl:
Scheme can be compiled to very efficient code that performs in the same
ballpark as C/C++, especially if you're not just talking about
micro-benchmarks, but rather about real systems.  In fact, the way Scheme
implementations usually achieve this efficiency is by compiling through
highly machine-optimized C - the kind of C code you couldn't write yourself
(or wouldn't want to).

As for the idea of implementing one high-level language in another, many
functional languages are self-hosting or partially so, and some of those are
excellent performers.

So, if one's goal is to implement a "scripting language", implementing it in
Scheme makes a lot of sense - you can leverage Scheme's language-building
features, ending up with a much smaller and more maintainable code base, and
you could easily generate a very fast interpreter binary.

If, OTOH, one's goal is to be a human compiler, by all means, keep churning
out that hand-crafted C code!  ;oP

Anton