In these emails I'll start documenting changes I make to the finalized
SRFI 231 and ask for opinions about possible future changes that I'm not
so sure about.

I've started updating SRFI 231 in a branch of my own repository:

https://github.com/gambiteer/srfi-231/tree/231-bis?tab=readme-ov-file

SRFI 231's sample implementation has already removed any difference
between "safe" and "unsafe" arrays.

The implementation now has (internal) unsafe getters and unsafe setters,
which are used in all block array operations, and the usual array
getters and setters always check their arguments for correctness.

In the sample implementation the parameter
specialized-array-default-safe? was ignored, and any safe? arguments
were passed around but not used.

So I've removed the notion of "safe" and "unsafe" from the SRFI
document, sample implementation, and tests.

I removed array-freeze! from the library. (The procedure %%array-freeze!
exists and is used internally in the sample implementation).

Calling (array-freeze! A) may reasonably suggest to a user that the
elements of A could no longer be modified, but with reified setters that
may already be stored in structures or variables to be used later, there
was no way to guarantee this short of setting the backing store to be
immutable.

These changes are noted in the list after my signature.

Brad

Things to change in a future library:

1.  There should be a single library, without "safe" and "unsafe"
versions.  Invoking (array-{getter|setter} A) checks the validity of
arguments.  (Done.)

Perhaps %%array-unsafe-{getter|setter} should be exported as
array-unsafe-{getter|setter} for library builders.

2.  Get rid of array-freeze! (Done)

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 interval-{every|any} as wrappers around %%interval-{every|any}.

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