[streams-standard-discuss] simple-streams

[Daniel Barlow]

David Lichteblau:
> Problems with the simple stream approach include streams which are
> buffered in a sense, but in a different way than the original protocol
> designer hoped they would be.  For example, string streams are special
> case which users would not be able to implement if the simple streams
> implementation would have provided for that.

Can you elaborate on that?  It seems that a basic "read buffer, write
and empty buffer, seek to position" interface could easily implement a
string output stream if the write-and-empty-buffer didn't empty it but 
instead saved it and gave the caller a new buffer (perhaps contiguous)
to scribble the next block in.  Am I missing something important, or
does simple-streams not allow this?

> Problems with CMUCL's ANSI-STREAM include that they are structures and
> that other implementations might not willingly adopt some ad-hoc object
> system in its stream layer just for compatibility with, say, SBCL.
> OTOH simple streams, while simpler due to CLOS, seem to struggle with
> that CLOS usage: As far as I understand it, there are funny attempts at
> optimizing CLOS access away which are not exactly beautiful.

I wouldn't expect that any homebrew object system will get widespread
traction any time soon: I think this is a problem that CMUCL/SBCL face
and will have to solve for themselves with some kind of proxy/adaptor
interface.  </handwaving>


-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/20040916/f367f620/attachment.sig>