[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES
- To: ROSENKING@A.ISI.EDU
- Subject: Re: Issue: STREAM-ELEMENT-TYPE-EXAMPLES
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 27 Oct 88 13:07 EDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: <[A.ISI.EDU]27-Oct-88 09:47:10.ROSENKING>
[added CL-Cleanup back, I think the whole subcommittee ought to
see these discussions]
Date: 27 Oct 1988 09:47-EDT
Thank you for your comments and recommendations. I wrote this issue
based on reviewing the examples in the STREAMs chapter of the draft.
I agree that there is an inconsistency among implementations, as I have
found via several trials, over which type specifier(s) should be returned.
BUT, is it not our task to correct this by at least stating what the generic
type specifier, and possible subtype specifiers, should be returned in the
standard ? If this is so then I would appreciate some feedback on what the
general consensus is as to what type specifiers, and appropriate subtypes if
necessary, should be returned.
Yes and no. Certainly, tightening up the standard to eliminate unwanted
inconsistencies among implementations is legitimate business of the
cleanup committee. Since there is ten or more times as much such
business available as there is time to do, things have to be prioritized,
and I'd rate stream-element-type low on the scale of importance. However,
the more important issue is that perhaps the differences among implementations
in what stream-element-type returns are not unwanted inconsistencies at all,
but are intentionally provided implementation freedom. CLtL doesn't
appear to address the specific issue of stream-element-types, but my
belief is that the intention of the original design was that the :element-type
argument to OPEN says the minimum type required, and an implementation is
free to return a more capable stream whose element-type is a superset.
Your testing is also finding bugs in individual implementations, which is
certainly valuable. Sometimes the bug indicates an unclarity in the Common
Lisp language definition, sometimes it just means the implementation was
sloppy. If several implementations have bugs in a particular area, it might
mean that in practice no one cares about that area and so bugs have gone
As per your note about examples, I will pass this on to the rest of the
editorial committee since I believe that it may apply elsewhere.