One argument array-for-each, array-every, and array-any?

[Gambiteer]

NumPy basically limits array broadcasting to pointwise operations, or array-map. I think that in a Scheme/Racket library without array comprehensions, one would need to implement broadcasting for arguments to array-fold-left and array-fold-right, too.

The argument processing of SRFI 231's array-for-each, array-every, and array-any is identical to the argument processing of array-map. Because SRFI 231's array-map always returns a generalized (non-strict) array, those "action" procedures can be restricted to have a single array argument without any change in behavior or performance.

I haven't yet committed such a change to my working repository

GitHub - gambiteer/srfi-231 at 231-bis

My question is: I the following too "un-Schemely"?

In Scheme/Racket the routines map, vector-map, every, any, etc. actually apply the procedure to the components of the arguments and return a result, i.e., they are "action" procedures. When array-map in math/array returns a non-strict array, as it does in all circumstances in SRFI 231, array-map just sets up operations to be executed later, relying on later "action" procedures to execute things.

If I change array-for-each, array-any, and array-every to take only a single array argument, that simplifies the implementation, the documentation, etc., with no change in performance or expressiveness, but will programming like the following examples in draft documentation seem too weird?

One can combine array-map with "action" procedures like array-for-each, array-any, and array-every to achieve the following:

(array-every (array-map = A B))         ;; are all elements of A and B =?
(array-any (array-map positive? A))     ;; is any element of A positive?
(array-for-each (array-map write-u8 A)) ;; write a byte array

So basically array-every, array-any, and array-for-each would just evaluate in order the elements of the single array argument, with different rules for when to stop and what to return.

Comments?

[Gambiteer]

I've updated array-for-each, array-every, and array-any to take a single (array) argument, and updated the test file srfi-231/test-mini-arrays.scm at 231-bis · gambiteer/srfi-231 · GitHub I'd be interested to know whether people find this programming pattern (to call these routines with the result of array-map as the sole argument) to be natural.

The five routines that step through all multi-indices in an interval and apply functions to those multi-indices with different kinds of control flow are interval-{for-each|every|any|fold-left|fold-right}.

The first three differ only in when they stop stepping through the multi-indices of an interval (step through all multi-indices; stop when a false value is a result; stop when a true value is a result). Unless we want to allow arrays that can return multiple values I don't see how to do that with array-fold-left and array-fold-right, so I believe those will continue to take multiple array arguments.

[Gambiteer]

Some discussion from the SRFI 231 mail list (Re: Proposal to reduce the number of argument to array-for-each, array-every, and array-any | Simplelists) about the difference between arrays and other "collection" data structures seems relevant here:

On 11/25/25 04:32, Alex Shinn wrote:

On Tue, Nov 11, 2025 at 8:22AM Bradley Lucier <xxxxxx@purdue.edu
mailto:xxxxxx@purdue.edu> wrote:

The old behavior can be obtained with

(array-for-each (apply array-map f array arrays))
(array-every (apply array-map predicate array arrays))
(array-any (apply array-map predicate array arrays))

So a lot more explicit array-map's in code, with the benefit that it's
clear that array-for-each, array-every, array-any just evaluate
elements
of an array in order, with different control-flow semantics.

I think this is kind of weird from a user perspective. Especially when
used to other collection SRFIs where we generally have:

(*-for-each f seq0 seq1 ...)
(*-every predicate seq0 seq1 ...)
(*-any predicate seq0 seq1 ...)

Yes, I agree it is "kind of weird".

I've come to think of generalized arrays ("nonstrict arrays" in Racket's
math/array), stateful procedures that carry their domains around with
them, as weird enough that they don't count as "collection" data
structures like lists, vectors, hash tables, trees, etc.

The documentation for Neil Toronto's math/array library in Racket states

To use nonstrict arrays effectively, think of every array as if it were
the array's procedure itself. In other words,

 An array is just a function with a finite, rectangular domain.

Some arrays are mutable, some are lazy, some are strict, some are
sparse, and most do not even allocate contiguous space to store their
elements. All are functions that can be applied to indexes to retrieve
elements.

The two most common kinds of operations, mapping over and transforming
arrays, are compositions. Mapping f over array arr is nothing more than
composing f with arr's procedure [f on the left]. Transforming arr using
g, a function from new indexes to old indexes, is nothing more than
composing arr's procedure with g [g on the right].

I've added the interpolated phrases [...].

So array-map, which always returns a generalized array in this proposal, is unlike the other *-map procedures. It doesn't immediately transform a collection of items into another collection of items. The fact that the procedure "-map" in its name is misleading (as I found out from some correspondence with users of the SRFI 231 sample implementation).

I believe that having array-{for-each|any|every} take only a single argument may emphasize to users that arrays are different to other collection data structures.

And perhaps we should rename array-map to array-compose to emphasize its true nature.

Any comments?