[r6rs-discuss] an essay on language design

From: Thomas Lord <lord>
Date: Tue, 24 Jul 2007 01:03:18 -0700

Let's set aside the ratification question -- you and I agree "yes", I guess.
Let's just say something about this notion of "piling features on top
of...."

The historic Scheme -- the very first stuff from Steele and Sussman --
stood out in the literature of its time because it reduced what was then
regarded as a big basket of messy problems into just a small number of
straightforward problems in a very pragmatic way. Semantically, everything
in the historic language reduced to lambdas and ifs/ands/ors and procedure
application. What stood out was that that same reduction that made it easy
to explain semantics *also* mapped directly and simply to how to implement
both a compiler and an interpreter. You could explain a loop by CPS
conversion. You could explain nested scopes with closure conversion.
Etc. These explanations not only provided unprecedented lucidity when
writing standards and utility when proving theorems -- but also, directly,
told you how to implement the language. It was just strange icing on that
cake -- the cake being that serendipitous and simultaneous resonance of
solutions at many
levels of thinking -- that Scheme got to show off with lexical scoping
and fully upward funargs in an error when people were palpably frustrated
by the absence and/or expense of these in other environments.

One thing that has changed since the early 70s are our common expectations
about the functionality and context of programming languages. We now,
more than then, expect a framework for modular development, string handling
for real-world Internet protocols, etc. Steele and Sussman were
exciting because
they simplified then messy issues like flow of control constructs,
nested scopes,
and upward funargs -- but these days those problems are taken as "done
deals"
no matter what and the expectations of a language or more of a "growable"
programming environment like CL or Java.

So, how to reconcile the classical "avoid piling on features" aesthetic and
trickery of the original Scheme with these modern demands?

R6 is going to miss "sweet, sweet, perfection" on that reconciliation,
by a good country mile. The library system, for example, is a whole
big bundle of little details to get right and, nowhere in sight is there
some
simple trick (akin to CPS conversion) that just reduces all of that library
stuff to a few primal, directly implementable ideas. (I'm not good at
articulating this point of view but it's the desire for this
reducibility that
leads me to suggest, not really joking, ideas like "R6 should just add first
class environments and fexprs").

I've reconciled myself to R6 partly by thinking it's useful, partly that
it's an accurate report on where folks are at -- but also partly because
it seems like a challenge problem: "simplify *this*, if you can" it seems
to beg for.

If you know what I mean.

-t



Michael Sperber wrote:
> It's hard to disagree with the grand statement per se. Indeed, the
> ratification candidate doesn't always avoid piling features on top of
> features. However, the same is true of R5RS and the Revised Reports
> before that. Should they never have seen the light of day? I prefer
> that they did. R5.97RS is the best shot the editors could come up with
> within the constraints of time and the process. Is it perfect? Far
> from it. (Unless you apply Matthias F.'s definition.)
Received on Tue Jul 24 2007 - 04:03:18 UTC