Quick comments on SRFI 127 Sudarshan S Chawathe (21 Oct 2015 00:01 UTC)
Re: Quick comments on SRFI 127 John Cowan (21 Oct 2015 11:32 UTC)
Re: Quick comments on SRFI 127 Arthur A. Gleckler (21 Oct 2015 15:17 UTC)

Quick comments on SRFI 127 Sudarshan S Chawathe 21 Oct 2015 00:01 UTC

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.

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

   "generator" -> "lseq"?

* 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.

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

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

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

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

* 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.

* 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?

* (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.

* (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.

* 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.

* 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.

* 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.

* 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).

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

* 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?

Regards,

-chaw