Sudarshan S Chawathe scripsit:

>   * lseq-second is used but not defined (though it is easy to infer
>     the intent as a generalization from SRFI-1).

Fixed.

>   * The in-order property of lseq-for-each may be more obvious with a
>     slightly modified example, something like:
>
>       (let ((v (make-vector 5)))
>         (lseq-for-each (let ((count 0))
>                          (lambda (i)
>                            (vector-set! v count (* i i))
>                            (set! count (+ count 1))))
>                        '(0 1 2 3 4))
>         v)

Adopted.

>   * lseq-filter and lseq-remove: Is it true that the dynamic order in
>     which pred is applied is unspecified, as it is for lseq-map?

I suppose it should not be.  Text added.

>   * For some of the searching procedures (lseq-find, lseq-find-tail,
>     lseq-memq, ...,  and lseq-assq, ...), is there a guarantee the
>     predicate is evaluated on the lseq elements in sequence order and,
>     further, only when necessary (i.e., short-circuiting)?  (The
>     descriptions of lseq-any, lseq-every, and lseq-index do specify
>     in-order short-circuiting applications.)

Yes, there is (except for the association procedures, which have been flushed).

>   * The expression just before lseq-take-while is introduced seems
>     like it belongs closer to the comment about "general-predicate
>     variant of the lseq-member function."

Well, it's an example, so I've left it with the examples.  The comment
before it has been rewritten to refer to lseqs, though.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Most languages are dramatically underdescribed, and at least one is
dramatically overdescribed.  Still other languages are simultaneously
overdescribed and underdescribed.  Welsh pertains to the third category.
        --Alan King