Thank you for your comments.  My responses are interspersed.  Changes
are in my local copy for now, which I will put on github later.

On 09/24/2016 08:00 PM, Sudarshan S Chawathe wrote:
> These comments refer to Draft #12 published: 2016/9/17.
>
> Most, but not all, are very minor.  The comments are in roughly document
> order, not significance order, so I hope folks won't punt on the whole
> message because of the nitpicky/trivial nature of the first few. (They
> get better, I think!)
>
> I'm sorry to get these in so late given today's "last call" deadline.
> As such, they are the result of a rather rushed reading, and so are
> somewhat more likely than usual to reflect problems at my end.  I'll
> also note that I have only skimmed the previous messages on the list, so
> it is possible some items have been discussed already.
>
>   * (trivial, naming) Is the ->vector part of the name
>     interval-lower-bounds->vector (and interval-upper-bounds->vector)
>     motivated by the need to distinguish it clearly from
>     interval-lower-bound (and interval-upper-bound)?  Otherwise, it
>     seems interval-lower-bounds (and interval-upper-bounds) would be
>     more natural, since the objects provided to make-interval are
>     vectors.

Originally I had *->list and *->vector procedures.  Both these
procedures provided new copies of the data.

I then followed a suggestion to get rid of the *->list procedures.

John Cowan suggested that I say what happened if someone later modifies
an argument to make-interval or the result of the *->vector procedures;
the answer is nothing, I make a copy of the vectors going in and a copy
of the arguments coming out.

So, should I now rename the *->vector procedures?

>
>   * (trivial, formatting) Odd formatting for code explaining
> 	  interval-volume.  (Probably a missing 'pre' tag.)
>
>       (apply * (vector->list
> 						     (vector-map -
> 						        			 	 (interval-upper-bounds->vector interval)
>       			 								 (interval-lower-bounds->vector interval)))
>
>     A similar comment applies to the code that explains
>     generic-storage-class.  There are a few other similar instances
>     elsewhere in the document.

Some places I use <pre>, some places I use <blockquote>, <code>, and
<var> (mainly where the code involves arguments to procedures).  I
changed this one instance to make it clearer.

>
>   * (minor) Should the signature for interval-contains-multi-index? read
>
>       interval-contains-multi-index? interval index-0 index-1 ...
>
>     following the Scheme reports convention (I think) that ... denotes
>     0-or-more of the preceding?  (The following text does clarify the
>     point, since d > 0, so this change would just emphasize the point.)

Changed.

>
>   * interval-curry: In the explanation, there is an instance of
>     left-dimension that should probably read right-dimension.

Fixed.

>
>   * (minor) interval-for-each: It was not initially clear to me
> 	  whether the procedure f is required to accept multi-indices
> 	  separately (one argument per dimension) or combined as a single
> 	  list of indices.  Given the definition of an interval as a set of
> 	  multi-indices, I interpreted an element of an interval to be a
> 	  tuple/list of indices and so was leaning toward the latter, but
> 	  the sample implementation implies the former.  It could just be my
> 	  misreading of earlier material, though. (A similar comment applies
> 	  to interval-reduce.)

A multi-index is not a list, it is what's returned by "values".  What
"values" returns is not reified in Scheme, it can only be consumed in a
closure accepting multiple values.

If you want to call what's returned by "values" a tuple, then a
multi-index is a tuple, not a list.

I realized that interval-reduce can be defined in terms of array-reduce
(just introduce an appropriate array by (make-array interval f) and
apply array-reduce), so I eliminated interval-reduce

>
>   * (nit) interval-permute: The correspondence is obvious, but the
>     text here refers to the dimension of the permutation while the
>     definition of permutations earlier calls it length.

I changed the earlier reference to refer to the "dimension" of a
permutation.
>
>   * make-array: In the second and third paragraphs of the explanation,
>     'array' should read 'make-array'.  There are a couple more
>     instances in the paragraph just before the example too.

Fixed (I think).

>
>   * array-map: Should the constraints on f be noted (although they
>     can be inferred)?

I added a sentence of explanation.

>
>   * array-curry: There seems to be a missing pair of parentheses in
>     the example.  I believe
>
> 		  (equal? ((array-getter A) i j k l)
> 	            (array-getter ((array-getter B) i j k) l))
>
>     should read
>
> 		  (equal? ((array-getter A) i j k l)
> 	            ((array-getter ((array-getter B) i j k)) l))
>
> 		instead.

Fixed.

>
>   * array-curry: Defining A and B as in the example, I get an error
>     when I attempt, for example,
>
>       ((array-getter B) 2 3 5)
>
>       =>
>
>       *** ERROR IN (console)@48.1 -- Wrong number of arguments passed
>       to procedure (#<procedure #12> 2 3 5)
>
>       (using the sample implementation with Gambit v4.6.0).

Wow, you are a close reader.  Fixed by defining B as (array-curry A 1).
(I changed the second argument from the left dimension to the right
without changing the example.)

>
>   * Related to above: The following yields true (using the sample
>     implementation), perhaps suggesting an inconsistency between the
>     SRFI and implementation on which "side's" (inner v. outer)
>     dimension is specified by the second argument to array-curry.
> 		(Perhaps this is linked to the left- v. right-dimension confusion
>     for interval-curry noted above.)
>
>       (equal? ((array-getter A) 2 3 5 7)
>               ((array-getter ((array-getter B) 2)) 3 5 7))
>
>       => #t

You're right, I fixed the example, I think
>
>   * array-curry: I am having trouble interpreting the statement:
>
>      The type of the subarrays is the same as the type of the input
>      array.
>
>     Here, does "type" refer to the mutability or domains of the
>     (sub)arrays, or Scheme types, or something else?

I added a sentence of explanation.

>
>   * array-permute: I don't think I understand the significance of the
>     subtlety noted in the explanation (regarding permuting arguments,
>     etc.).  Is it a result of the convention used for permuting
>     intervals, and similar to the "usual" confusion when multiplying
>     permutations (cf. Knuth TAOCP 7.2.1.2."A general framework"), or
>     something else?  I suppose it doesn't really matter for the
>     purpose of the SRFI, but I got the feeling I am missing some point
>     here.

Many mathematics textbooks specify a permutation by giving its range,
with the domain elements implicit, so the permutation function 1->2,
2->1, 3->4, 4->5, and 5->3, or the set of ordered pairs (listed in order
of the first element of the pairs, i.e., the domain element)
$$
\{(1,2),(2,1),(3,4),(4,5),(5,3))\}
$$
is written as
$$
(2 1 4 5 3).
$$

It didn't seem natural to me to work with permutations in this way, so
this SRFI we list the pairs in increasing order of the second elements
of the pairs (the range):
$$
\{(2,1),(1,2),(5,3),(3,4),(4,5)\}
$$
and then I specify the first elements, with the second elements implicit:
$$
(2 1 5 3 4)
$$
I didn't want to say too much about what I don't do, and rather spend
the time explaining what I *do* do.

I can't find the word "framework" in TAOCP 7.2.1.2 from

http://www.cs.utsa.edu/~wagner/knuth/fasc2b.pdf

>
>   * (minor, formatting) Some (pseudo)code in the array-permute section
>     seem to be missing 'pre' tags or some such.

Yeah, sorry, I can't mix mathjax $\pi$ with <pre>, so I'm stuck with
this formatting.

>
>   * interval-reduce (and array-reduce): The order of the arguments in
> 	  invocations of the provided 'operator' seems to differ from that
> 	  used by the analogous (I think) reduce procedure from SRFI 1.  Is
> 	  this difference intentional?
>
>   * Related to above: interval-reduce and array-reduce seem closer to
>     SRFI 1's 'fold' than to its 'reduce' procedure (though the above
>     comment applies in either case).
>
>   * Would it make sense to include array-fold (and interval-fold)
> 	  either in addition to or instead of the -reduce procedures?

I'll have to think about this.  To do fold-right properly one should
introduce a function (array-reverse A), which contains the same entries
as in A, with the same domain, only in reverse lexicographical order.
Maybe that's the way to go.

>
>   * array-body: Is the returned object the same as the object created
>     by an application of the maker argument to the storage-class of
>     the array? (A clarification near its definition may help; I found
>     things hard to follow.)

It's *an* "object created by an application of the maker argument to the
storage-class of the array".  But after a specialized array has been
curried, permuted, and translated, the array elements themselves might
occupy only a small subset of the body, and be stored in a rather
strange order.

Do you think something needs to be said?

Brad