On 12/2/25 19:01, Alex Shinn wrote:
>
> On Tue, Dec 2, 2025 at 1:24 AM Bradley Lucier <xxxxxx@purdue.edu
> <mailto:xxxxxx@purdue.edu>> wrote:
>
>     On 11/25/25 04:32, Alex Shinn wrote:
>      >
>      > It's also easier for implementations to fast-path certain cases
>     without
>      > always requiring an intermediary map.
>
>     I don't quite understand this.  Outside of error checking, the code in
>     the sample implementation is the same either way---first compose f or
>     predicate with the argument arrays' getters and call the associated
>     interval-<whatever> procedure. (This isn't true for
>     array-fold-{left|right}, so these procedures still take multiple array
>     arguments.)
>
>
> For one example:
>
> ;; generalized dot product
> (define (array-dot a b)
>    (let ((sum 0))
>      (array-for-each (lambda (ai bi) (set! sum (+ sum (* ai bi)))) a b)
>      sum))
>
> Here if a and b are both specialized arrays, array-for-each can use
> more efficient indexing, without the need for intermediary multi-indices.

Interesting example.

I think you'll need that a and b are both specialized and packed.  And
nontrivially broadcast specialized arrays are not packed.

The sample implementation does something similar in %%move-array-elements.

> Even without that optimization I think the intermediary map, if not inlined,
> would hurt the loop performance, but it may be worth benchmarking.

I suppose the library should not be specified in a way that impedes a
wide range of implementations, from simple implementations that make
minimal attempts at optimizing the code, to moderately complex
implementations (I'd say that your proposed simplified array indexing
for packed specialized arrays falls into this category), to full-blown
pedal-to-the-metal implementations (like PetaLisp's JIT compiler).

Having array-{any|every|for-each} take a single array argument would not
impede a JITed implementation if each array carried around with itself a
symbolic representation of the expressions used to build that array, but
may impede moderately complex implementations that have local
optimizations like you suggest.

I'll have to think some more about this.

Brad