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.

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

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

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

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

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

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

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

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

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

  * 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

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

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

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

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

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

-chaw