[r6rs-discuss] Issues with section 8.2. Port I/O, a.k.a. (rnrs io ports (6))

From: Shiro Kawai <shiro>
Date: Mon, 27 Aug 2007 17:01:42 -1000 (HST)

From: William D Clinger <will at ccs.neu.edu>
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
Received on Mon Aug 27 2007 - 23:01:42 UTC