Multidimensional arrays in Scheme

[Alaric Snell-Pym]

Dear Marco and Bradley,

In the ongoing work of Scheme standardisation for R7RS, the question of
standardising multidimensional arrays in Scheme has arisen, including
such thorny questions as: Do we adopt Bradley's SRFI-231, or might it be
in some way incompatible with "Heisig's JIT approach"?

We would therefore be honoured if you would both attend our next meeting
to discuss this; or if not, offer your opinions via email in advance of
the meeting so we can choose the best path forward (I have Cc:ed our
mailing list - postings to it from non-members may be moderated for
anti-spam reasons, but they'll be manually approved in due course)

We are currently choosing the time for our next meeting (they're held
online in IRC - no travel budget required!):

https://terminplaner6.dfn.de/p/dab5fb151bc65c155fbbd8961cccec7e-1650649

If you would be willing and able to join us, please put your
availabilities in the poll!

As some background, here are the minutes of the meeting where we decided
to postpone the discussion until we had expert opinions:

https://codeberg.org/scheme/r7rs/wiki/Minutes+2025-11-21.-

Many thanks for your time,

Alaric Snell-Pym
(Acting chair of R7RS WG2)

--
Alaric Snell-Pym (M0KTN neé M7KIT)
http://www.snell-pym.org.uk/alaric/

[Alaric Snell-Pym]

Bradley and Marcio are both happy to join us!

-------- Forwarded Message --------
Subject: Re: Multidimensional arrays in Scheme
Date: Thu, 12 Mar 2026 15:13:49 +0000
From: Bradley J Lucier <luc...@purdue.edu>
To: Alaric Snell-Pym <ala...@snell-pym.org.uk>
CC: Bradley J Lucier <luc...@purdue.edu>, marco....@mpl.mpg.de
<marco....@mpl.mpg.de>, scheme-re...@googlegroups.com
<scheme-re...@googlegroups.com>

Thank you for the invitation to your next meeting, I have noted the
times I can participate.

I have been working to refine SRFI 231 to make it more suitable for
standardization; the most important changes are to remove the notion of
“safe” and “unsafe” arrays (all arrays are now safe, but the sample
implementation removes unnecessary safety checks in the built-in “bulk”
array operations), and to add both explicit and implicit array
broadcasting in the style of NumPy in Python or Racket’s math/array
library. This update (which includes several new extended examples) can
be found at

https://github.com/gambiteer/srfi-231/tree/231-bis

The changes from SRFI 231 are listed after my signature.

I read the wiki notes from the recent R7RS committee meetings. I’ll
comment now briefly that SRFI 231 (and the followup) adds no new syntax
for arrays, and I believe that operations with what SRFI 231 calls
“specialized” arrays are compatible with Marco’s JIT compilation
approach in PetaLisp.

Brad Lucier


This SRFI differs from the finalized SRFI
231<https://srfi.schemers.org/srfi-231/> in the following ways:

* The implementation no longer specifies, or implements, a
difference between "safe" and "unsafe" arrays. The getters and setters
of all arrays made in the library check array indices for correctness;
the setters of mutable specialized arrays check that the objects they
store into arrays are of the correct type. (Internally, the sample
implementation maintains "unsafe" setters and getters that are used in
"bulk" array operations where the arguments are known to be
appropriate.) So procedure arguments that specify whether array results
are "safe" have been removed, as has the parameter
specialized-array-default-safe?.
* The calling sequences for interval-fold-left and
interval-fold-right have been changed.
* array-freeze! has been removed as a user-visible procedure.
Because array setters are reified and can be stored in structures,
passed as arguments, etc., one cannot truly "freeze" a mutable array to
make an immutable array.
* The default entry for arrays of generic-storage-class is now
0, not #f, which we find to be more useful.
* The routines array-outer-product and array-inner-product are
now specified to copy generalized array arguments to specialized arrays,
evaluating all elements of such an array in an unspecified order. The
procedure array-inner-productnow returns a specialized, not a
generalized, array result.
* Both explicit and implicit array broadcasting are specified in
this SRFI extension.
* The parameter array-broadcasting? has been added to the SRFI.
* The routines interval-every, interval-any, interval-rebase,
array-rebase, interval-insert-axis, object->array, array-insert-axis,
compute-broadcast-interval, array-broadcast have been added to the SRFI.


On Mar 12, 2026, at 5:43 AM, Alaric Snell-Pym <ala...@snell-pym.org.uk>
wrote:

[You don't often get email from ala...@snell-pym.org.uk. Learn why this
is important at https://aka.ms/LearnAboutSenderIdentification ]

---- External Email: Use caution with attachments, links, or sharing
data ----

[Wolfgang Corcoran-Mathe]

On 2026-03-12 17:09 +0000, Alaric Snell-Pym wrote:
> Bradley and Marcio are both happy to join us!

Thanks, Alaric! That's great news.

--
Wolfgang Corcoran-Mathe <w...@sigwinch.xyz>