Re: New multilingual text support

[Jim Blandy <jimb@red-bean.com>]

> > - I suppose read-char will read scm_char_t (same for read-line,
> >   etc.) according to some charset (port-specific?). We need
> >   primitives to do binary IO.
> > (binary-read size bytes [port]) => u?vector
> > (u8vector->number u8vector) => number
> 
> Note that you may not be able to mix character and byte I/O
> on the same port.  You may have to pick on or the other
> when you *open* the port.  The Java model is that character
> streams are wrappers that sit on top of byte streams.
> The problem is that the character stream layer may contain state
> (shift state or buffered data) such that it may be difficult
> (perhaps impossible) to synchronize it reliably with the
> underlying byte stream.

Guile is going to use that model, too.  Encodings are layers on top of
ports that write binary data.  Our port model needs (or already has?
I need to catch up with Gary) some sort of synchronization primitive,
so you can tell the upper layer, "settle things with the port under
you", frob the underlying port, and then go back to normal.  But I
haven't thought this through completely yet.


> The reflects problems in the underlying semantics:  Does it really
> make sense to consider a port a stream of bytes and characters
> at the same time?  Does it make sense for a file to be a text
> file and a binary file at the same time?  Probably not.

An individual port is either one or the other.  But a stream could
certainly contain a mix of binary data and text using some nice
encoding.  You have a "raw" port which is talking directly to the
outside world and carries raw bytes, and another port layered on top
of that which carries some textual encoding.  When you need to write
bytes, you use the raw port.  When you need to write text, you use the
upper port, and then synchronize it before writing more bytes to the
raw port.

Dunno.