1. Forum
  2. Usenet
  3. COMP.LANG.LISP

  • READ-SEQUENCE and fill pointers

    From Spiros Bousbouras@21:1/5 to All on Mon May 2 14:16:21 2022
    (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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Zyni=20Mo=C3=AB?=@21:1/5 to Spiros Bousbouras on Mon May 2 15:58:00 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tom Russ@21:1/5 to Spiros Bousbouras on Mon May 2 10:02:07 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Zyni=20Mo=C3=AB?=@21:1/5 to Tom Russ on Mon May 2 19:02:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Spiros Bousbouras@21:1/5 to no_email@invalid.invalid on Tue May 3 19:55:49 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)