sperber at informatik.uni-tuebingen.de
Thu Jul 13 10:04:55 EDT 2006
William D Clinger <will at ccs.neu.edu> writes:
> If it's true, then stating that it is true would help.
> If it's false, then stating that it is false would help,
> but you would still have to explain what kind of objects
> are acceptable as a descriptor.
I tried to do that in the latest draft. Better?
>> > I would guess that you are assuming a model in which some
>> > character, e.g. END OF TRANSMISSION, popularly known as
>> > control-D, is interpreted as an end of file when typed.
>> No. I'm assuming a model where the other end sends a block of data
>> and then pauses temporarily (i.e. stops typing).
> Wow. Please confirm:
No, you're right. I had my head somewhere the sun doesn't shine.
Your original statement quoted above is correct. Sorry about that.
> The only reason that is the only possibility is that it
> is the only means provided by this particular proposal.
> I do not accept your implicit assumption that this is
> the only possible means that could be provided.
It's not, but I've thought this a bit and couldn't come with anything
better. Maybe you can make a suggestion?
> I believe I suggested an alternative some time ago: provide
> a procedure that takes an input port and a transcoding, and
> returns an input port that uses the transcoding.
I considered that, but it is very difficult to implement efficiently.
(At least for me.) I believe PLT's implementation of these procedures
effectively turns off buffering on the underlying port, forcing the
decoding to happen character-by-character.
> Every continuable exception must be accompanied by a protocol
> that describes how the exception can be continued. In this
> case, I propose that an exception handler that wishes to
> ignore the situation simply return zero values, and that an
> exception handler that wishes to replace the situation with
> some sequence of replacement characters simply return those
OK, that can be done. I'd still like us to decide how we want to
handle encoding errors before I invest the time required to specify
and implement this protocol.
> The point is that buffering *can* be used, and will be more
> effective if implementations are allowed to design their own
> protocols than if they are required to support random things
> like set-output-port-buffer-mode! on every port.
I don't know that they're random: This exact model of controlling
buffering is common, for example, among SML's and POSIX's model, and
the available modes are certainly all useful.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
More information about the R6RS