[streams-standard-discuss] Welcome to streams-standard-discuss

[Daniel Barlow]

You are receiving this message because you signed up to the
streams-standard-discuss mailing list.  It appears to be the first
message sent to said list, so if you'd forgotten you subscribed and
you don't wish to be, there should be details of how to change this
in the footer.

So.  This list and its siblings (for threads and MOP) were set up
after discussions at the LSM 2004 in Bordeaux about areas of CL that
we thought were worth de facto standardization.  The discussion on
threads centered around a short presentation given by Rudi Schlatte

http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/lightning/lightning.html#htoc9

and discussion.  Note that I'm going from my unreliable memory,
reinforced by subsequent talks on IRC; this summary is by now more
indicative of my own opinions than any consensus we reached at the
time.  So, if you were there (and even if not), chime in.

The prime existing contenders for extensible streamas are "Gray"
streams and Franz' simple-streams.  In fact these solve different
problems.

Simple-streams are for when you have an external octet store of some
kind (e.g. a file) and simply want to write some code that fills it
with octets (when writing) or empties it of octets and makes them
available to client code (when reading).  It has some kind of
translations for "special" characters but in the end - correct me if
this is not true - everything comes down to a block of
characters/bytes/similar

We suspect the simple-streams specification to have infelicities
"around the edges" where it's not clear how much is intended to become
a standard and how much is just Allegro implementation that happens to
be based on simple-streams.  e.g. the interface in ACL to create a
socket stream, last time I looke at it, involved a call to some
MAKE-SOCKET function instead of the tidier MAKE-INSTANCE of
SOCKET-STREAM that you might have been hoping for.  I may be
misremembering this or I may be out of date; please feel free to
correct me.

Gray streams are intended to operate at a very different level.  An
implementation of a Gray stream might want e.g. to recognise objects
as they're output and remember their location on a graphical display;
it seems clear that digesting all the objects to text strings before
doing this is not The Right Thing, so the higher level interface is
also needed.

The common complaints about Gray streams are: (1) that it's not
specified which of the interface methods are used in the default
implementation of which of the others, so you end up having to
implement /everything/ yourself instead of knowing that, for example,
you can provide methods for stream-read-char and stream-listen and
will automatically get a working stream-read-char-no-hang.  (2) CLOS
dispatch in single charcter output is likely to be really rather slow

After reading a bit on some of the issues faced in i18n, I think Gray
streams have other issues too: I'm not convinced that an interface that
still talks in terms of column positions is necessarily going to be
so useful in a world of proportional fonts, bidirectional rendering,
asian languages and arabic, etc.  Just what _is_ STREAM-START-LINE-P
when rendering decimal numbers left-to-right inthe middle of a line of
right-left hebrew text?

The primary hat I'm wearing here is as an SBCL implementor: the
current streams mechanisms in SBCL are pretty grungey and really could
use some redesign at the 'device' (simple-streams-like) level.  It's
unikely that we'd adopt simple-streams wholesale - apart from anything
else our build process says we need streams before CLOS is available -
but something that is at least philosophically compatible with the
good bits would be nice.

OK, discussion is open to the floor.


-dan

-- 
"please make sure that the person is your friend before you confirm"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/streams-standard-discuss/attachments/20040915/38bef4e2/attachment.sig>