streams-standard-discuss

Download

streams-standard-discuss@lists.common-lisp.net

September 2004

5 participants
1 discussions

[streams-standard-discuss] Welcome to streams-standard-discuss
by Daniel Barlow 16 Sep '04

16 Sep '04

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"

5 10