Miscellaneous comments.  (Some may refer to issue that have been
discussed, but I missed it or don't remember.)

* I still prefer "shape" over "interval".

*The interval API is big.  This could be avoided if intervals
were vectors or arrays (as SRFI-25 shapes).  It is nice to
abstract away the representation, but not at the cost of
19 new procedures!

* Why require indexer functions be one-to-one?
It can be useful to map a domain to a small number of values.

* What the the use-case for indexer= ?  It seems expensive to calculate,
not very useful, and easy enough to implement if really need it.
The main argument I can see for putting it in the specification is
if an implementation can optimize it in certain cases.  But is it
actually useful for anything?

* Global variable specialized-array-default-safe?
Mutable global variable are a no-no.  A per-thread / fluid
variable might be ok, but fluid variable are not in R6RS, R7RS
or commonly implemented.  Instead, a "parameter" would be better.
Even better: Just remove it.

* Various introspection functions, such as array-indexer, may be
undesirable, as they constrain the implementation in keeping these
procedures in the original form.

* Why does specialized-array-curry exist?  Why wouldn't I use
array-curry or mutable-array-curry?

* I dislike specialized-array as a term.  It's too long, especially
considering it's the "default" kind most of us are going to be using most
of the time,

Note it is possible to implement the array and mutable-array constructors
using specialized-array by using a custom storage-class that calls the
getter and setter (if mutable).  (You'd have to do the inverse of the
indexer, but otherwise it seems straight-forward.)  Thus specialized-array
is actually fully general, and you don't need the other types.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/