Specification vs. Implementation Alex Shinn (23 Aug 2005 02:49 UTC)
Re: Specification vs. Implementation Michael Sperber (23 Aug 2005 07:24 UTC)
Re: Specification vs. Implementation Alex Shinn (24 Aug 2005 02:48 UTC)
Re: Specification vs. Implementation Per Bothner (24 Aug 2005 04:27 UTC)
Re: Specification vs. Implementation Michael Sperber (24 Aug 2005 17:28 UTC)
Re: Specification vs. Implementation Michael Sperber (24 Aug 2005 17:45 UTC)

Re: Specification vs. Implementation Alex Shinn 24 Aug 2005 02:48 UTC

On 8/23/05, Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> wrote:
>
> Alex Shinn <xxxxxx@gmail.com> writes:
>
> > SRFI-68 provides an implementation as its specification.  The
> > implementation is fully transparent, in that from a port object you can
> > access the underlying stream, and from a stream you can access the
> > underlying reader or writer primitive.
>
> That was the case in the beginning, but I dropped transparency two
> revisions ago, precisely because of what you argue.  Please check
> again.  Is it better now?

I've checked, and believe your referring to the change from

  A port is essentially just a reference cell to a stream.

to

  It is possible to construct ports from streams. Such a stream port is just a
  reference cell to a stream. The various procedures constructing ports
  described in this section are allowed but not required to return stream ports

[BTW, I love what Aubrey Jaffer did with SRFI-70, using strike-outs for
deleted text and additions marked in red.  I hope future SRFIs take up
this practice.]

This means the standard procedures for creating ports are allowed to
return ports based on the underlying I/O libraries with no relation to
the SRFI-68 streams or readers/writers.  There are still some
ambiguities though, since we have both STANDARD-INPUT-PORT and
STANDARD-INPUT-STREAM, and it's not clear what the relation between them
is and what happens if you use both.

Standard streams aside, an implementation that wanted to support SRFI-68
while still using its host platform's I/O libraries would still need to
add the SRFI-68 reference implementation in it's entirety, basing the
lowest reader/writer level on it's own high-level ports, and modify the
native port operations to distinguish between native ports and SRFI-68
ports.  This is a lot of redundancy and a lot of work.  For portable
code it would always be advisable to only use the port layer directly,
since in many implementations the lower layers and ports built on them
would be extremely slow, so the net result is that the bottom two layers
become dead weight.  It doesn't seem worthwhile requiring them.

--
Alex