William D Clinger <will_at_ccs.neu.edu> writes:
> What that means is that implementators will have to
> go to duplicate the functions of readers and writers
> in their port i/o, but programmers will still have to
> deal with readers and writers as a separate data type.
> It would be simpler for everyone if the functions of
> readers and writers were added to the port data type,
> and readers and writers were eliminated from the
> report.
As I said, that's possible (essentially by inlining reader/writer
construction with port construction from readers and writers), but it
eliminates opportunities for abstraction, such as creating future
libraries that create readers or writers from different sets of
primitives, or using a joint primitive infrastructure for other
approaches to I/O, such as the one in SRFI 80.
> Mike Sperber wrote:
>> I guess it would be possible to allow the creation of ports from
>> arbitrary sinks and sources without involving separate data types for
>> readers and writers. As this was a stated requirement for the design
>> of the I/O libraries, simply deleting readers and writers is not an
>> option---an alternative means for doing it would be a prerequisite.
>
> Where can we find these stated requirements?
The first mention is here:
http://www.r6rs.org/r6rs-editors/2004-November/000371.html
The first design that was a result of this thread was SRFI 68, which
also contains them in the Abstract. Requirement statements about
doing I/O on arbitrary sinks and sources are also in the Abstracts of
SRFI 79 and 81.
The I/O system in the R6RS draft lacks a requirement statement, but,
as you mentioned previously, its design is in some sense based on
those two SRFIs.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Wed Nov 22 2006 - 03:39:26 UTC