William D Clinger <[EMAIL PROTECTED]> 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 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
