Created
March 2, 2019 21:18
-
-
Save death/5356be28dc3332caa189c91880fe12c6 to your computer and use it in GitHub Desktop.
Rant about Gray streams
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Gray streams interface mirrors the ordinary streams interface | |
almost without change. This creates many issues: for example, if | |
one wants to define, say, a decompressing stream, which operates in | |
terms of octets, but also make it usable as a character stream, one | |
is left to implement character decoding by himself. Franz's | |
SIMPLE-STREAMS details more such issues. | |
For a while I've felt dissatisfied with Common Lisp streams. I | |
think it's because of the Gray streams interface, which are not | |
part of Common Lisp proper. | |
SBCL has an SB-SIMPLE-STREAMS contrib module, but it appears unused | |
because when I tried an example from Franz's documentation (the | |
WHIZ-BANG stream) it failed to work. I've fixed the bug and now it | |
seems to work again, but how many more bugs lurk there? | |
Franz's documentation is also lacking. I suppose it's because they | |
rely on the user to learn from the examples provided with Allegro | |
Common Lisp, but I am not an Allegro user. Thus, the next time I | |
want to implement a stream, it will happen with the help of the | |
contrib module's source code. | |
The final straw that led me to have such strong opinions about Gray | |
streams came from trying to use a GZIP decompressing stream as a | |
character stream for parsing GZIP-compressed XML. The | |
"gzip-stream" library, which uses Gray streams, has a | |
STREAM-READ-CHAR method that uses CODE-CHAR, and disregards the | |
stream type in STREAM-READ-SEQUENCE, always returning octet | |
vectors. Therefore it failed to parse. The "chipz" library, also | |
using Gray streams, doesn't even bother with character streams. | |
If these libraries were to use SIMPLE-STREAMS, they would only need | |
to implement the binary stream handling, and character translation | |
would be provided automatically. | |
I think Gray streams is a good example of how conflating two | |
different user types into a single (well, almost) interface can | |
create problems. Both stream users and stream definers deserve a | |
simple interface to help them perform their task. In the case of | |
Gray streams, which parrots the stream user interface, complexity | |
is created for the stream definer. | |
Before my GZIP drama I thought that the Gray streams interface | |
weird for mirroring the Common Lisp interface, and that it was | |
incomplete (no STREAM-FILE-LENGTH), and that it was annoying to | |
have duplication in implementing STREAM-READ-CHAR, | |
STREAM-READ-SEQUENCE, STREAM-READ-BYTE, but I didn't realize how | |
deeply it contributed to my dissatisfaction with Common Lisp | |
streams, and I didn't seriously think about an alternative | |
interface. Now that I've looked into SIMPLE-STREAMS, I feel better | |
about Common Lisp streams, and I feel like I need to bring myself | |
to think about alternative interfaces more. | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment