[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fill-pointers and sequences
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: Fill-pointers and sequences
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Fri, 22 Nov 1985 20:22:00 -0000
- Cc: Common-Lisp@SU-AI.ARPA
- In-reply-to: Msg of 22 Nov 1985 15:36-EST from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
- Sender: FAHLMAN@C.CS.CMU.EDU
I do not feel strongly about which way this issue is resolved, but I
agree that it should be tied down. I mildly favor a strict interpretation.
Okay, but I have to ask what we gain by making the user go through this 5-line
rigamarole when a simple call to FILL would suffice if the language were defined
the other way. To me, the fill-pointer is simply the current length and doesn't
mean that the rest of the vector does not exist in any sense (see the note on
p.295 that vector elements not in the active region are still part of the vector).
I guess the language is going to be ugly either way.
I also want to repeat my query which no one addressed yet: Does the answer
depend on whether the sequence function in question is one that writes
(like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?
We've got two data abstractions going here: the sequence and the vector
which implements it. I am suggesting that the stuff beyond the fill
pointer is in the vector, but not in the sequence. What we gain is a
nice clean image of what the sequence is, without a lot of special
cases. In my opinion, the read/write distinction should not matter --
generic sequence functions should not read or write beyond the current
boundaries of the sequence, though vector/array primitives like AREF and
SVREF may do so.