> We need binary I/O. Text and character I/O is only one kind > of data format, out of very many.
Right. The question at hand is whether we need it /in WG1-Scheme/. Maybe people who want to read jpegs should be using WG2? I can't help feeling that we've jumped prematurely into debates about the relative importance of specific obscure features when we first need to settle the question of why have WG1 at all. It /can't/ be a question of "what is the minimum needed to have something called Scheme" since we lived for quite a while with much smaller standards than even R5. I also don't really understand why even people who more or less like R6 are eagerly engaging in this conversation about WG1, while I've seen /nothing/ about WG2 -- unless that discussion has quietly moved to some less contentious forum. :-) Is it that nobody wants to think of their favorite feature as belonging to "bloated Scheme," or something like that? Maybe if nobody's interested in WG2 we don't need it at all, but instead need just WG1 plus an "accessories catalog" like the one that came with my new bybrid? You don't have to have a cargo net, but if you want one, we have a genuine official one for you. [Warning -- half-baked ideas follow.] But actually I don't want to take that path, because then there will be pressure for WG1 to include all the building blocks that accessory writers might need to be able to write their accessories -- blobs, and so on. I want WG2 to be the only-slightly-bigger-than-WG1 language that supports all the possible accessories, and WG1 to admit nothing that isn't jewel-like, no matter how useful it might be. So certain accessories might not work with WG1. Under those rules I might have one of each, WG1 to teach my students with, and WG2 to do actual work with. So if most of the bells and whistles go into the accessory catalog, and both WG1 and WG2 have 50-page standards (or maybe WG2 gets up to 60), people who want to discuss the most expressive and efficient lowest-level building blocks for the building of abstract types would feel good about having that discussion under the WG2 tent. When we had the first round of argument about Unicode, its proponents somehow (not on purpose, I'm sure) led me to believe that in order to support Unicode I had to (1) give up case-insensitivity, and (2) become an expert on the esoterica of various encodings in order to be able to program in Unicode-Scheme. This time around, I've learned that Unicode actually /does/ support a usable level of abstraction, so that I can have strings that are sequences of the kind of thing that I want to call a character (an entire character, not, e.g., an accent), and that they provide an official case- (and other-weirdness-) folding algorithm. Great! Jewel-like Unicode. I'm in. Let's leave headache-inducing Unicode for WG2, whose users will want finer control for efficiency reasons or to solve obscure problems that not everyone needs to solve. This position is counterintuitive, I know, because I'm advocating putting in WG1 an abstraction that, in WG2, would be written in Scheme using lower-level tools that (my idea of) WG1 just won't have. It might well turn out that you can't write a really efficient WG1 interpreter in WG1-Scheme, and that implementations of WG1-Scheme will routinely be written in WG2-Scheme. That won't bother me, as long as you can write a metacircular WG1 interpreter, even if it's inefficient. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
