Sudarshan S Chawathe scripsit:

> I read this SRFI with interest.  My comments are all quite minor;
> some, marked (minor) or (nit), even more so.  They are based on things
> that puzzled me during a fairly quick read.

Thank you for your highly detailed and useful comments.

Arthur, I have pushed the corrections to
<http://www.ccil.org/~cowan/temp/srfi-127.html>; please push to the site.

> *  "In order to prepend a realized value to a generator, simply use
>    cons;..."

It should have said "to an lseq"; fixed in my local copy.

>    "generator" -> "lseq"?

I'm not sure what you are asking here.  This procedure accepts a generator
and returns an lseq that contains the values produced by that generator.

> * I don't have any suggestions for a fix (given the explanation in the
>   SRFI), but I find it a bit troubling that lseq?  may return true for
>   improper lists whose last cdr is a procedure with arguments, i.e.,
>   for non-lseqs.  What bothers me is that something that yields #t
>   with lseq? may not be an lseq acceptable to some other
>   lseq-accepting procedures.  Perhaps this situation is not so
>   uncommon; I'm unsure.

It is troubling, but it is a consequence of reusing existing Scheme
data structures (in this case, procedures) rather than using completely
new abstract ones.  In this case I think ease of use beats theoretical
perfection.

> * Why does lseq-zip insist on at least one lseq being finite?

That's an error; fixed.  I was in fact working on the implementation
when your email came in.

> * Shouldn't the return value for lseq-map (and lseq-pair-map) be lseq
>   instead of unspecified?

Fixed.

> * Given the other examples, an example for lseq-pair-map would be
>   nice.

I have flushed lseq-pair-map and lseq-pair-for-each, as I can't find
really compelling use cases.

> * In the example for lseq-for-each, "lambda (lseq-) ..." should be
>   "lambda (i) ...".

Fixed.

> * The example just above the Searching section title seems like the
>   wrong one for that spot.  It's identical to the previous example, for
>   lseq-for-each.

Copy and paste disease.  I have created proper examples.

> * The example (lseq-find even? '(3 1 4 1 5 9)) => 4 would be nicer if
>   the list included another even number (to illustrate the first-match
>   semantics).  '(3 1 4 1 5 9 2 6) perhaps?

Fixed.

> * (minor) May be nicer to move the paragraph contrasting
>   lseq-find-tail with lseq-drop-while to the description of the latter
>   (which appears later), to avoid a forward reference.

Done.

> * (nit) In the description of lseq-any: "The application of pred to
>   the last element of the lseqs is a tail call" seems a bit odd to me.
>   I am not sure something like "last application of pred in the
>   sequence of applications just described" is any better (assuming
>   it's correct).  Ditto for the description of lset-every.

References to tail calls flushed.

> * It may be nicer for the examples following the (very useful)
>   reminder "Note the difference between lseq-find and lseq-any..." to
>   include a non-#t return value.

I've created an example using factorial (which returns #f on a negative
argument).

> * In two of the examples for lseq-memq and lseq-member: I couldn't
>   find the explanation for the form (lset 'a).  Is it a lset
>   constructor, or should it read (list 'a)?
>   Ditto in the examples for lazy association lists.

Cut and paste disease.  Changed to (list 'a), as you conjectured.

> * In: "The comparison procedure is used to compare the elements ei of
>   lseq to the key x in this way: (= x ei) ; lseq is (E1 ... En)" The
>   'E's at the end should be 'e's.
>   Ditto in the examples for lazy association lists.

Fixed.

> * Seems like an lseq-find is missing in the example just before the
>   Lazy association lists section (else I didn't understand the point
>   there).

Removed the reference to lseq-find.

> * (nit) 'An "lazy association list"' -> '"A "lazy..."'?  Hmm..., may
>   be it's an "L.A.lists"... then it would work!

Cut and paste disease.  Changed "an" to "a".

> * Example just before Sample Implementation section: "lazy alist" ->
>   "lazy-alist"?  Further, shouldn't the lseq-first be car, since the lazy
>   alist contains just the usual pairs?

Fixed.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
There are books that are at once excellent and boring.  Those that at
once leap to the mind are Thoreau's Walden, Emerson's Essays, George
Eliot's Adam Bede, and Landor's Dialogues.  --Somerset Maugham