From: William D Clinger <[EMAIL PROTECTED]> Subject: Re: [r6rs-discuss] Issues with section 8.2. Port I/O, a.k.a. (rnrs io ports (6)) Date: Mon, 27 Aug 2007 21:32:40 -0400
> I (and many others) have already described quite a > few. After the official R6RS document is published, > when it will be easier to tell the difference between > typos and deliberate mistakes, I will compile a list > of the deliberate mistakes, including those that have > already been described. I'll have to do this anyway > when I make a list of the R6RS misfeatures that are > deprecated in Larceny. This makes me wonder. Is it possible to have a SRFI that describes "discouraged" features in, or "amendments" to, the standard? Even R6RS will have quite a few libraries, the real-world applications will require a lot more. So I expect that lots apps/libraries will necessarily (and conveniently) describe prerequisites as "R6RS + SRFIa + SRFIb + SRFIc + ...". It may be convenient that we can express the amendments in the same terms. Advantages? For example, srfi-1 has become so popular and lots of libraries have depended on it, that a newcomer naturally comes to learn srfi-1 as well as Scheme itself, and someone who starts a new Scheme implementation would think he'll support srfi-1 functions from the beginning. Similarly, if R6RS + srfi-xx (amendment srfi) becomes so popular that many other apps & libraries say they work with srfi-xx, then newcomers will look at the srfi as well as the standard document, and new implementors may think to optimize for R6RS+srfi-xx rather than for the bare R6RS. Such srfi may also serve an experiment field to see what we should do in R7RS. --shiro _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
