Re: binary-io (was Re: rfc 2045 base64 encoding/decoding module)

["C. Ray C." <crayc at 206 dot 31 dot 63 dot 15>]

On Sat, Feb 12, 2000 at 01:25:15PM -0000, Gary Houston wrote:
> R5RS has managed to avoid letting its character type degrade to a byte
> type, by the simple device of never introducing the concept of a byte.

So, while it makes the standard useless -- as useful implementations
must either treat characters as bytes or do something such as introduce
another type -- it does support multibyte characters =^D.

> RXRS has no need to go down the route of defining a new type for
> larger character sets, since its existing character type can be as
> wide as you want anyway.  Instead it's up to anyone who wants to go
> beyond R5RS and process foreign data to introduce any new types
> required.

I can imagine few practical programs that don't need to deal with
foreign data.  R5RS, I think, doesn't go far enough in specifying
something here. Ideally, the standard should say "here is what you do to
deal with text" and "here is what you do to deal with everything else",
but all it says is "you can read and write characters".

This is reminding me of Pascal... people say, "Oh, it's a teaching
language" so they cripple it and refuse to deal with the sometimes
difficult topics that programmers need to deal with -- when in fact,
it could be a useful language. Then implementers just add the things
they need to make it useful, and the standard ends up not standardizing
anything important.

Anyways, you're right, the character type in Scheme can still be used
for Unicode or whatever else, unlike C. We just need something to deal
with foreign data.

> > I would prefer simply a new type, called "byte", an 8-bit numeric type,
> > and then "read-byte", "write-byte", "byte->integer", "integer->byte"
> > and "byte?" procedures. This is sufficient to do anything I can think
> > of with external data.
> 
> How about reading a UDP packet from the network?  The interface has
> the interesting property that you have to read the whole thing at
> once: anything you don't read is then lost.  Likewise in reverse for
> generating a packet to send.

Well, it could be saved and then read a byte at a time. Make a "UDP port"
type, where each packet is accessed through a port. But I don't know
anything about UDP, so I can't argue this with any conviction...