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