a (revised) draft of R5RS

[Kent Pitman <kmp@harlequin.com>]

cph> The only way I can see to resolve this is to have two languages.  

Wouldn't work for me because I believe there is never any shame in nor lack
of grace in finding a way to explain hard things.  Your analysis would lead
one to believe that Newtonian physics was clean and elegant and Einsteinian
physics just gunked things up by making things more complicated.  I'm saying
that for Scheme being "clean and pretty" may be a necessary condition but
is not "sufficient"--to be sufficient, it must be capable of really letting
people program or at minimum describing in a semantically clean way what
happens when they do.  I don't see a WAY (even a hard way) to describe what
will happen when escape procedures meet unwind-protect unless you require
programmers to say what their intent is upon invocation of an escape procedure,
and that in turn leads me to believe you have not made a "sufficient" 
description of the language.

If you made two languages, I would insist on being on the committee that
designs the elegant one because my concern is about elegance, not about
efficiency.  If we have made a mistake, it is in our definition of elegance.

I do not accept that the shortest semantics is most elegant.    Sometimes
more complexity in the "definition" leads to "shorter programs".  Language
elegance and program elegance are in tension, and it seems to me both are
worth considering--and, I think, sometimes the users deserve to win.  There
are, after all, more of them.  I think there's a certain elegance in 
optimizing the whole work of programmers + language designers, not just the
work of language designers.  Every time I hear someone say "smaller is better"
I think you're just chanting Dick Gabriel's worse-is-better thing: put it all
on the back of the user.  There's a loss of algorithmic complexity and 
modularity in doing that, in my opinion, and it's more elegant to solve the
problems that people really do a lot centrally.  

I do not accept that an elegant semantics is sufficient if it does
not give useful meaning to common programs that people need to write
and does not offer an alternate means of writing such programs.
After all, the most trivial semantics (one with zero rules) is by far
the most elegant--it just doesn't do anything.  So we'll say it just falls
short of a few goals required to be "useful" and leave it at that--why
mess it up with things that only complicate matters and still don't reach
our actual goal?