[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: STREAM-INFO (Version 4)
- To: Masinter.email@example.com
- Subject: Issue: STREAM-INFO (Version 4)
- From: firstname.lastname@example.org (Richard C. Waters)
- Date: Mon, 27 Jun 88 11:19:15 EDT
- Cc: CL-Cleanup@sail.stanford.edu, KMP@stony-brook.scrc.symbolics.com
- In-reply-to: Masinter.email@example.com's message of 24 Jun 88 12:17 PDT <880624-121812-5897@Xerox>
While relying on implementation-specific heuristics for
implementation-specific streams seems right to me, it seems less clear
for streams that are created using otherwise portable mechanisms.
This is a good point. However, I agree with KMP that we do not want to load
this proposal up with a lot of baggage.
For example, we could define that for string streams created, the line
width is the value of *string-stream-width* (and encapsulated in the
stream), where NIL means infinite, and that the unit of width is 1 and
that every character takes exactly 1 character,
Here, it seems to me that that logical width of a string stream is
infinity. I would not add any extra hair. It is the user who
presumably has some theory about how wide the stream should be. Any
reasonable pretty printer or the like will have a way for the user to
override the inherent width of a stream.
that two-way-streams and echo-streams inherit the position and
width of their output streams,
This sounds good to me.
that broadcast streams inherit from their first component.
I agree with KMP's comments on this. Things do not seem all that simple.