William D Clinger <will at ccs.neu.edu> writes:
> More than twenty years have passed since I wrote this [1]:
>
> Programming languages should be designed not by
> piling feature on top of feature, but by removing the
> weaknesses and restrictions that make additional
> features appear necessary. Scheme demonstrates that
> a very small number of rules for forming expressions,
> with no restrictions on how they are composed,
> suffice to form a practical and efficient programming
> language that is flexible enough to support most of
> the major programming paradigms in use today.
>
> I still believe that first sentence, and I still believe
> Scheme ought to demonstrate what is claimed in the second
> sentence, but the draft we are being asked to ratify does
> not always do that.
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.)
As far as "piling feature on top feature" is concerned, the great thing
about the statement is that the notion is so vague that people often
understand it in different ways. (Witness the variety of things that
have been advocated using it on comp.lang.scheme.) In particular, just
about any "record proposal" I've seen piles features on top of features.
The procedural layer---with which you seem to have no major
gripes---piles at least this together:
1. new disjoint types
2. positional addressing
3. opacity
4. inheritance and sealedness
Most of these could be separated out, some of them quite easily. (For
example, early versions of the reference implementation separated out
opacity, as well as new disjoint types + positional addressing.) Would it
have been worth it? Hard to tell.
I personally would have preferred a more modular and orthogonal design,
but I'm satisfied by the fact that the procedural layer can be
decomposed to some degree while retaining the same interface. However,
it does appear that the features piled on top of each other with the
records mechanism are often needed together. The syntactic layer has
the advantage that aspects such as inheritance or opacity don't show up
in record-type definitions where they are not relevant.
You point out my lack of insight into the performance implications of
the design decision we made. No doubt my lack of insight into many
issues have made the candidate draft worse than it could be, and a
number of mistakes made it in. By me, we also retained a number of
serious mistakes made in R5RS or before, but such is life. I will point
out that the aspect of the syntactic records layer you're criticizing
has been on the table publically since late 2005, and no alternative
designs (on top of the same procedural layer) were available before the
candidate draft. (The general issue is still mentioned in the "Issues"
section of SRFI 76, along with the fix we put into R5.97RS.) I still
prefer what we currently have over what you propose. Moreover, I think
the feature pileage in the procedural layer is far more substantial than
the addition of `parent-rtd' to the syntactic layer.
So, it's pretty clear that we could improve upon what we have given more
time, and, if things remotely work out, the successor to R6RS will
indeed improve upon it. However, the editors had to draw the line
somewhere: otherwise, nothing would ever have come out. Depending on
how you count, R6RS is at least 9 months overdue.
> The second reason has to do with what happens after
> the vote. As I see it, there are three possible
> outcomes:
>
> 1. The vote is negative, which would give the
> editors an opportunity to get it right.
>
> 2. The draft is ratified, and everyone pretends
> to live happily ever after.
>
> 3. The draft is ratified, and the unhappy folk
> design alternative syntactic layers, probably
> written up as SRFIs, that build upon the R6RS
> procedural layer.
All possible roads that lead to ratification end in:
- Something less than perfect gets ratified.
I'm also on the record for saying:
- No matter what the syntactic layer, somebody will be sufficiently
unhappy with it to write up their own.
PS:
> The system I am about to describe is, in one of Mike Sperber's
> favorite phrases, a conservative extension of the 5.97 record system.
I don't know what my favorite phrases have to do with this, but, for the
record, my favorite phrases in the English language are (please excuse
the profanity; I'm European):
1. bad-ass motherfucker
2. sex monster
3. pimp my ride
...
276. old cuisine
277. conservative extension
278. kangaroo court
...
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Tue Jul 24 2007 - 02:57:38 UTC