On Sun, Dec 4, 2016 at 2:21 PM, Sudarshan S Chawathe <xxxxxx@eip10.org> wrote:

  * Should interval= be named interval=? instead, by analogy with
    string=?, char=?, etc.?

This is an area where inconsistency is unavoidable.
Scheme itself contrasts numeric = with char=? and string=?.
SRFI 1, which is roughly contemporary with R5RS, set a
precedent by naming its equality function list= without
specifying what it returns, and several other Red Edition
SRFIs founded directly on SRFI 1 followed suit at least
as to the name.  So in effect it is the personal taste
of the SRFI author that controls.

  * Since interval-intersect? returns a usable 'true' value, should it
    be named interval-intersect, by analogy with member, etc

I agree.
 
  * Arrays and intervals are specified as being Scheme types different
    from all others.  However, storage classes do not seem to have
    this requirement.  I am guessing this design is intentional,
    perhaps to make some optimized implementations easier, but am not
    sure.

I thought it was an oversight, and urge it to be provided.
 
  * In the description of specialized-array-default-safe?, is the #t
    intentionally specific, or is any true value (i.e., anything other
    than #f and #false) permissible there?

Since it is both an accepted and a returned value, and final ? implies
a return value of exactly #t or #f per R4RS/R5RS/R7RS 1.3.5, I think
the spec should restrict the argument to exactly #t or #f.
  
Similarly, there are a few places
    where an argument is restricted to being a boolean.  I assume this
    would be interpreted as limiting valid values to those for which
    boolean? yields true.

I try wherever possible to strongly type arguments in specs, as it helps
optimizing compilers with type inference, and it is still possible
in the case of booleans for implementations to accept
arbitrary values as true.  

        * Would it be desirable for array->list to guarantee lexicographic
    traversal of the array (similar to the guarantee provided by
    array->specialized-array)?  If such a guarantee is added, then it
    would also propagate to array-fold and array-fold-right given
    their definitions in terms of array->list.]]

I strongly agree: that guarantee is pretty much essential.  Imagine running
array->list on a u1 array and getting back all the zeros followed by all the ones!
 
  * Given array-every?, should array-any? also be provided?

I've been reluctant to suggest new procedures, since a later SRFI can always add
them, but this one does seem like a glaring hole.

  * SRFI 25's array-ref and array-set! permit array indices to be
    provided either as separate arguments or as a vector or as a
    1-dimensional array.  Would a similar strategy be useful for the
    relevant procedures of this SRFI?

I think that kind of ad hoc overloading is un-Schemish.  Scheme tends to
favor either universal polymorphism (sometimes implemented by an ad hoc
scheme under the covers, as with `write`), or monomorphism.  (If you want
Common Lisp, you know where to find it.)
 
-- 
John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
Pour moi, les villes du Silmarillion ont plus de realite que Babylone.
                --Christopher Tolkien, as interviewed by Le Monde