(let ((arr (make-array 20 :fill-pointer 0 :initial-element 1))
(s (make-string-input-stream "abcdefg")))
(read-sequence arr s)
(close s)
(format t "~a~%" (aref arr 0)))

prints 1 .But if I change the above code to :fill-pointer 1 then it
prints a .This both on SBCL and clisp so I'm guessing it's standard.
But from where in CLHS does it follow that READ-SEQUENCE should not
read beyond where the fill pointer is ? I find the behaviour counter-
intuitive. Perhaps I don't understand the logic of fill pointers but
I have been assuming that you allocate for a vector a number of
elements which you think will prove useful over the running of your
programme and at each point in time the fill pointer indicates up to
which position your vector has meaningful values. If you do
READ-SEQUENCE into your vector , you indicate that you want the vector
filled with as much as the vector can fit in and the stream can
provide. So I would find it more intuitive that , if the stream can
provide characters to fill up to and including position N in the
vector and before the READ-SEQUENCE the fill pointer had some value
M <= N then after the READ-SEQUENCE the fill pointer will have the
value N+1 .

--
There's nothing I like less than bad arguments for a view that I hold dear.
Daniel Dennett

Spiros Bousbouras <spibou@gmail.com> wrote:
> But from where in CLHS does it follow that READ-SEQUENCE should not
> read beyond where the fill pointer is ?

read-sequence sequence stream &key start end => position
[...]
position---an integer greater than or equal to zero, and less than or
equal to the length of the sequence.

And from length (is link in CLHS)

length n. (of a sequence) the number of elements in the sequence.
(Note that if the sequence is a vector with a fill pointer, its length
is
the same as the fill pointer even though the total allocated size of
the
vector might be larger.)

--
the small snake

On Monday, May 2, 2022 at 7:16:28 AM UTC-7, Spiros Bousbouras wrote:
> (let ((arr (make-array 20 :fill-pointer 0 :initial-element 1))
> (s (make-string-input-stream "abcdefg")))
> (read-sequence arr s)
> (close s)
> (format t "~a~%" (aref arr 0)))
>
> prints 1 .But if I change the above code to :fill-pointer 1 then it
> prints a .This both on SBCL and clisp so I'm guessing it's standard.
> But from where in CLHS does it follow that READ-SEQUENCE should not
> read beyond where the fill pointer is ?

It may not say that in so many words, but I would assume it is implied
as Zyni notes. In particular, the default END value for READ-SEQUENCE
is NIL, which is interpreted as the length of the sequence. And as Zyni
mentions, this is the active length of the vector with fill pointer.

If you were to change your output to be
(format t "~a ~a~%" arr (aref arr 0))
you would see that the value of ARR is empty: #()

AREF can still access the inactive element 0 because AREF is specifically
defined to ignore fill pointers and thus able to access inactive elements
of the vector. [I had been wondering why that worked].

You could also examine the return value of READ-SEQUENCE, which would
also show that no values were read. The consequence of this is that the
READ-SEQUENCE function will not extend arrays, but only operate on the
active values.

Tom Russ <taruss@google.com> wrote:

> You could also examine the return value of READ-SEQUENCE, which would
> also show that no values were read. The consequence of this is that the
> READ-SEQUENCE function will not extend arrays, but only operate on the
> active values.
>

One consequence of this is this thing

... compiler does fancy calculation about bounds, optimises bounds
checks ...
(read-sequence ...)
... calculations still valid ...

--
the small snake

On Mon, 2 May 2022 15:58:00 -0000 (UTC)
Zyni Moë <no_email@invalid.invalid> wrote:
> Spiros Bousbouras <spibou@gmail.com> wrote:
> > But from where in CLHS does it follow that READ-SEQUENCE should not
> > read beyond where the fill pointer is ?
>
> read-sequence sequence stream &key start end => position
> [...]
> position---an integer greater than or equal to zero, and less than or
> equal to the length of the sequence.
>
> And from length (is link in CLHS)
>
> length n. (of a sequence) the number of elements in the sequence.
> (Note that if the sequence is a vector with a fill pointer, its length
> is
> the same as the fill pointer even though the total allocated size of
> the
> vector might be larger.)

That settles it ; thanks.