[R6RS] I/O

[Michael Sperber]

William D Clinger <will at ccs.neu.edu> writes:

> The writer-bytes object does not have access to a simple
> reader.  Any connection between a reader and a writer
> must therefore be made in ways that are not described
> by the primitive i/o layer.  I am therefore mystified
> by your argument.

More confusion, I'm afraid.  The descriptor is not for communication
between a reader and a writer.  It is for communicating between the
constructor of a writer and a procedure that accesses some aspect of
the writer.  There's `open-bytes-writer' and `writer-bytes,' which
communicate.

>> The model is that you have a byte sequence with interleaved
>> end-of-files which goes on indefinitely.  For a finite data source, it
>> ends in an infite sequence of end-of-files.  I've tried to describe
>> this better.
>
> The scream you hear was occasioned by my horror of
> this semantics.  What is the rationale?

The intermittent end-of-files are a natural by-product of incremental
or interactive data sources.  The trailing infinite sequence of
end-of-files is from R5RS, and is consistent with that notion.

> I don't understand it either.  I think my confusion
> was caused in part by the extensive use of pronouns
> (e.g. it) with ambiguous antecedents, and in part by
> the absence of any semantics for transcoding.

I guess that got lost in the shuffle.  I'll try to do better tomorrow
morning.

>> No.  The prefix of the byte sequence forms an encoding of a scalar
>> value, and it's unambiguous when that sequence ends.
>
> In other words, no such compositions are to be formed.

Yes.


> Rather than invent a side effect that can be used
> at any time, in any way, including the most inappropriate
> ways and times that can be conceived, why not allow
> an input port to be opened on inputs that may describe
> their byte order in the standard way, allowing the byte
> order to default in the standard way?

Because there is no "standard way", as far as I can tell.  Different
environments and conventions allow for different sets of BOMs, for
example.  The full set of BOMs doesn't allow unambiguous determination
of the encoding.  (Moreover, there's XML which contains the name of
the encoding on the first ASCII line, if I understand it correctly.)

> It appears that you are requiring transcoders to
> replace invalid, incomplete, and unsupported
> encodings by question marks.  I question whether
> this is consistent with Unicode conformance
> requirements C5, C6, C7, C11, and (especially) C12a.

That's possible---I took this behavior from PLT Scheme, after
discussing it with Matthew.  Alternative suggestions?

>> > set-output-port-buffer-mode!:  Might there be some
>> > inefficiency associated with requiring every output
>> > port to support this operation?
>> 
>> I don't think so.
>
> But I do.

Then you'll have to explain where you think the inefficiency is.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla