[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Requests for clarification
- To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
- Subject: Requests for clarification
- From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
- Date: Sun, 19 Aug 84 00:33 EDT
- Cc: STEELE@TL-20A.ARPA, common-lisp@SU-AI.ARPA
- In-reply-to: <RAM.12040528780.BABYL@CMU-CS-C.ARPA>
Date: Sat, 18 Aug 1984 19:19 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
We haven't bothered too much yet about implementing the four types of
multiple streams (broadcast, concatenated, two-way, and echo) since they
are ill-specified and not terribly useful (i.e. we'll do them, but they
aren't high priority).
For a stream constructed with make-two-way-stream, what is the result
of applying stream-element-type to the stream, especially if the
element-types of the two underlying streams are different?
In Spice Lisp, Stream-Element-Type returns an Or of the distinct
stream element types for the component streams if they are different.
obviously lazy implementor could return T.
This seems reasonable to me.
How does the close function operate on various non-primitive streams?
For example, does close of a two-way stream close the two underlying
streams? What about close of a concatenated stream?
In Spice Lisp, closing any multiple stream results in closing all of
the component streams.
This seems reasonable to me, although I can think of arguments (from experience
on Multics for instance) against it.
As a concatenated stream hits eof on each subsidiary stream, are those
subsidiary streams closed?
Spice Lisp doesn't do this, and I think that's the right thing to
do. In the case of a file stream, hitting eof doesn't necessarily
make the stream useless, so you don't want to go around automatically
closing the things.
I assume that if you try to read past EOF on a subsidiary stream it advances
to the next stream, but lets you FILE-POSITION back into earlier streams?
Then none of the component streams are closed until the concatenated stream
is closed. This seems reasonable.
An explicit statement should be made as to how equal and equalp treat
structures. DO structures fall under the general heading of "objects
that have components"?
There better dammn well be some predicate that works on structures,
so I guess it's got to be equalp. I guess we could make equal work on
structures as a special case, but that would have interactions with
In our system EQUAL and EQUALP treat structures the same as arrays. This
seems the most consistent with the manual pp.80-82. Thus EQUAL is never true
for structures unless EQ is, and EQUALP is true for structures of the same
type with the same components. This is all assuming you don't use the :TYPE
option to DEFSTRUCT.