Implications of updated sample implementation Bradley Lucier 19 Apr 2025 17:14 UTC

Implications of the updated sample implementation:

1.  The sample implementation ignores the safe? arguments and
specialized-array-default-safe? parameter.  If a user invokes

(array-ref A i j ...) or
((array-getter A) i j ...)

directly, then those procedures check that the arguments are
appropriate;  none of the bulk array operation check the arguments of
getters/setters (there are separate unsafe getters/setters) because they
don't need to.  (The sample implementation still follows the SRFI
specification, which says that if specialized arrays are "safe" then
they check the validity of their arguments.)

2.  All bulk computations are crammed into %%interval-fold-{left|right},
%%interval-{every|any}, and %%move-array-elements.  (%%interval-for-each
calls %%interval-fold-left with a special trivial combining operator.)

%%interval-fold-{left|right} are user-callable as
interval-fold-{left|right}, it seems to me now that
%%interval-{every|any} should also be user visible.

I think these interval-<whatever> procedures are important because lots
of operations are like "Find the multi-index that satisfies blah, blah,
blah about an array" and these operations can be implemented uniformly
in terms of interval procedures instead of specialized array procedures.

3.  I am convinced that a (perhaps heavyweight) representation of arrays
can be concocted so that all the bulk operations of this SRFI can be JIT
compiled to nested loops, as in Petalisp:

https://github.com/marcoheisig/Petalisp

This was always a concern for me, part of the reason why I restricted
multi-index transforms to affine transforms, but I now believe it to be
true.

I've updated my list of things to change in a future library based on
these observations.

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.  Perhaps %%array-unsafe-{getter|setter} should be exported as
array-unsafe-{getter|setter} for library builders.

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