I'd like the SRFI 231 sample implementation not to crash when presented
with user code that is valid, but "strange" (e.g., invoking
continuations multiple times, modifying lists that are passed as
arguments to library procedures, etc.).

I'd also like the library not to check every low-level operation, i.e.,
checks should be done at a higher level that allows low-level loops to
not check that every index is within the extend of a vector, etc.

Recently, I realized that with the specification of storage classes in
terms of procedures (getter, setter, checker, maker, copier, length,
etc.), that allowing these procedures to be user-defined, "full
powered", Scheme procedures, more checking/copying would be needed to
avoid crashes in internal procedures.

For example, this commit

https://github.com/gambit/gambit/commit/e4d7411a4f4eab266678db2f1126cebafb8d0ea2

copies valid nested list/vector arguments before beginning to assign
elements to a newly allocated array body in case the storage class
setter modifies the arguments and changes their contents/structure,
which could cause later unchecked operations to crash.

I believe these changes avoid the possibility of crashing, but there are
other uses of storage class procedures that are embedded so deeply into
assumptions of how low-level array operations behave, that I'm not
confident that crashes can be avoided completely.

So I've come to the conclusion that we should get rid of user-defined
storage classes in general, and the procedure make-storage-class in
particular.

In the Gambit implementation, no low-level storage class operations have
internal error checks, it is assumed that checking occurs at a higher
level, e.g., that f32vector-ref is applied only to f32vector bodies,
that computed indices into the f32vector body are in range, etc.

So maybe storage classes should be completely opaque, I don't know.

But I'm pretty sure that user-defined storage classes, and particularly
make-storage-class, should go.

Brad

Things to change in a future library:

1.  (srfi 231) is "safe", with an "unsafe" library (srfi 231 unsafe);
mixing safe and unsafe arrays and operations could be accomplished by
renaming routines.

2.  Get rid of array-freeze!

3.  Do not fix the order of evaluation of array elements in arguments to
the "bang" (!) procedures.

4.  Add (array-rebase array [lower-bounds]) to translate an array to
given lower bounds.

5.  Add broadcasting of arrays and adding new axes to arrays.

6.  Add a notation for quickly specifying Bawden-style array
transformations similar to that of NumPy or Racket's math/array.

7. Remove user-defined storage classes.  Perhaps make storage classes
opaque.