From: Martin A. <ma...@at...> - 2001-10-15 17:45:56
|
Nathan Froyd wrote: > > I was playing around with Martin Atzmueller's excellent NET.SBCL.SOCKETS > package and discovered that the following call: Thanks. > (READ-SEQUENCE BUFFER SOCKET) > > where SOCKET is a Gray stream variant, doesn't work. The relevant lines > seem to be in src/code/stream.lisp, roundabout line 454, function > READ-N-BYTES, where the STREAM argument is declared as LISP-STREAM, > rather than calling it a STREAM and then taking the appropriate action > on a LISP-STREAM or Gray stream. Yes, the code for dispatching on the stream-type is "missing" if you compare this function with all the others, that differentiate a stream vs. a gray-stream, e.g. fundamental-stream. When I wrote the code for net.sbcl.sockets, I realized, that the gray-stream proposal didn't say anything about read-/write-sequence and such. Nevertheless these functions come in handy ... but it's a pity, that a solution to this problem is an "extension" ... We could go for the approach taken by ACL: - have two new generic functions STREAM-READ-SEQUENCE and STREAM-WRITE-SEQUENCE: These would by called by READ-SEQUENCE, and WRITE-SEQUENCE, if called on a gray stream. And, > What would be the best way to efficiently read the bytes (characters, > maybe?) out of a Gray stream? they could also be specialized on whatever is appropriate for the gray-stream at hand. Btw, what do people think about adding a new keyword to OPEN, that would allow for creation of "other" stream classes, subclasses from fundamental-stream??? This is non-ANSI, but a) constructors for gray-stream-classes are missing from the gray-stream proposal, so this, or some other constructor-mechanism, probably makes sense. b) ACL has this as an extension, too. Cheers, Martin -- Martin Atzmueller <ma...@at...> |