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

[Gary Houston <ghouston at arglist dot com>]

> Date: Sat, 12 Feb 2000 17:14:20 -0600
> From: "C. Ray C." <crayc@206.31.63.15>
> 
> > > 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...

Yes, that seems like a plausible way to handle it.  There's also the
point that converting data between Scheme and a foreign format is
likely to use serial, not random access to the foreign data.  Maybe
this would also be the case for some of the FFI and mmap applications.
It doesn't seem any worse to define a new port type over a range of
machine addresses than a shared uniform byte-vector.  So maybe a
port-centric interface isn't so bad after all.

The only disadvantage I can see is that there may still be
applications, like the video frame buffer example, where it would be
better to use a vector to access the data.  In these cases the stuff
defined on a port would not be usable, so there may be some
duplication of functionality.