Sorry for being very late in following up on this message.

I am including below some comments on the few items from the earlier
message that still apply to the recent draft 14, dated 2016-11-28.  (I'm
also working through draft 14 more systematically and hope to post some
(mostly minor) additional comments by tomorrow.)

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

I think this is very similar to the issue addressed in Knuth's
discussion of permutations.  It appears on pages numbered (printed) 8
and 9 in the above copy (PDF page numbers 12, 13).  Searching for
'framework' indeed gives no results; something to do with the PDF
encoding perhaps.

I am not sure if using the other convention for applying a permutation
to a sequence (array/interval indices in the present case) would help
any (probably not, as it would just reverse the problem).  The main
issue seems to be that the semantics of array-permute require the
ability to 'apply' both the given permutation and its inverse, which I
guess is a bit awkward implementation-wise.

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

Still minor, of course, but for what it's worth, given the either-or
situation, my preference would be formatting without mathjax.  It's
probably just a reflection of my difficulty with reading unindented
code, though.

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

I think so.  The new draft (14) doesn't seem to explicitly define
array-body explicitly at all, unless I missed it somehow.

Sorry again for the very late follow-up,

Regards,

-chaw