This page is part of the web mail archives of SRFI 75 from before July 7th, 2015. The new archives for SRFI 75 contain all messages, not just those from before July 7th, 2015.
me: > I think it might be realistic to label ports not with
> the encoding scheme they want, but with the set of
> code-values they can transmit -- in other words
> with their framing constraints.
John: The difficulty here is that an ISO-8859-1 port {produces,accepts}
a different set of characters from an ISO-8859-2 port. Unless a
port is labeled with an encoding, you can't know what characters it
will and won't {accept,produce}, and you are stuck with some system
default.
There is no reason I can see why the implementation must provide
the kind of labeling you like. I have no trouble imagining
many applications that don't need it --- they either won't
need the system to enforce a restriction because they'll know
what their ports are talking to or they are robust in the case
that they get wrong what the ports expect. The goal
here isn't to try to prevent programmers from making mistakes.
The whole "port encoding labeling" thing seems plausible to many
of us but I think there is precious little actual experience
in how to do it, that multiple ways are possible, and that the
goal for R6RS should be to enable experimentation in this area
by portable programs.
For example, a common suggestion is that you specify when
first creating a port what encoding it is. Well, what if
I hope to send traffic over that port that will use different
encodings at different points during the run? Clearly labeling
is not trivial -- I'd say, not well understood.
-t