David Van Horn scripsit: > Thanks for posting these notes. My biggest concern with what you've > proposed is that there is nothing small about adding 43 new identifiers > and 7 more lexical syntax notations to R5RS.
Considering that R5RS has 187 bound identifiers, the growth is less than 20% in over ten years (twenty years, really; see below). I don't think that's so bad. There is no plausible way to count the number of lexical syntax features in R5RS (are numbers just one feature, or a group of features?), and I haven't tried. Note: Counts of identifiers are either mine or Aubrey Jaffer's, and are not guaranteed correct. > Several of the items you mentioned can be implemented well portably, so > I was surprised to see them on the list (like SRFI 8 and 11). I deliberately said "biased toward" rather than "confined to". > Rather than adding this and that new binding, I think it would be more > fruitful to work on a "small" library system. All of these bindings > could then just be imported when needed. The document shrinks > dramatically in size and complexity. This is the heart of the matter. The questions "Should this identifier be in a module?" and "Should this identifier name a required feature of the standard?" are entirely orthogonal, yet often conflated. R6RS has a whopping 665 bound identifiers, almost all of which are in libraries. But since a conformant R6RS system must provide all of those libraries, little or no additional implementor flexibility is granted thereby, and users must go to the trouble of specifying the libraries they use (though there is a handy compound library that joins almost all of them). I say "little or no" because a smart R6RS compiler might be able to use a different runtime if it knows that, say, mutable pairs are not in use. Dismissing for the moment the matter of whether identifiers are in libraries, then, we must confront the question: "Why make a particular identifier a required part of the standard?" Sometimes the answer is "Because it's primitive, and we can build useful things on it." Sometimes the answer is "Ancient tradition." But the most satisfying answer, to my mind, is "Because that's what a Scheme programmer expects to find when they move to a new implementation." If something like receive is in wide use, is widely implemented, doesn't cost a fortune to specify or implement, and Scheme programmers expect to find it in their implementations (perhaps after uttering some magic like "(require-extension (srfi 8))", then there is a strong prima facie case for standardizing it. Similarly, if let, let*, and letrec are present, someone might well expect to find letrec* (at present, R5RS allows letrec to be implemented either like R6RS letrec or R6RS letrec*). > One of the major dimensions R6RS grows in compared with previous > reports is in the complexity of its lexical syntax. I'd like to see > much of that cut from the small language. Do we really need 3 different > comment syntaxes in the most basic incarnation of the language? Maybe not. I'll settle for ; and #;. > My feeling is we need a very small, but extensible, base language. > The base should allow for semantic and lexical extension that will > encompass all of R5RS and R6RS, but it should enjoy a specification > with the level of complexity of about R3RS. You might be interested to know that R3RS has 190 bound identifiers, slightly more than R5RS. Scheme has never been a really small standard. > All of the lexical complications of bytevector syntax, syntax syntax > (the literal notation for syntax objects), Unicode, etc., should be > pushed out of the "small" language. This posting is long enough, so I'll discuss blobs and Unicode later. My views on them are more nuanced than you probably think. > All of the library complications of phases and versions should be > pushed out. Agreed. I'll talk about that in a later posting. > If possible, the semantic complications of multiple values, the dynamic > environment, exception handlers, etc., should all be pushed out, into > libraries, or the "large" language. In short, I think we should try > to tear down R6RS to a small basis that lets us build it back up again. The trouble is, where do you stop? After all, we know what the minimal basis is, namely just identifiers and lambda -- everything after that can be figured out by a smart compiler. Of course, your integers may not interoperate with mine, but so what? The theoretical purity of the language must and shall be preserved! The fact is that whatever purity Scheme ever has had doesn't reside in the procedures and library syntax that it standardizes. That's grown and shrunk by Darwinian selection, the most impure process imaginable. -- And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a [email protected] great strength of will to turn it to other http://ccil.org/~cowan purpose, he saw only two aged hands withering in flame. --"The Pyre of Denethor" _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
