On 10/28/24 02:16, Alex Shinn wrote:
>
> Re: 3, I'm not sure the example of an array that reads successive elements
> from a file is convincing.  In general the array elements could be read many
> times in an arbitrary order, so I don't see how broadcasting aggravates
> this.

This was an argument to allow broadcasting of only specialized arrays.

If you want to broadcast a generalized array you can copy it to a
specialized array; I think this is sufficient.

Usually the argument to specialized-array-broadcast would have many
fewer elements than the result (which usually shares many times each
element of the argument, without copying), so an initial array-copy
would not be an unreasonable requirement.

> Re: 4, I think implicit translation to the origin is perfectly
> reasonable, but am
> also fine with requiring it to already be at the origin.  If we do
> require this
> we should have a domain predicate array-at-origin? in addition to the
> array-to-origin utility.

I just had the thought that if the array is already at the origin, the
result of array-to-origin would be the identity, so perhaps
array-at-origin? wouldn't be needed.

But I see that the sample implementation doesn't do this for
translations, permutations, or reversals of arrays.

And furthermore, quite a few procedures are specified to return "new"
intervals or arrays where, strictly speaking, being "new" is not an
essential requirement.  (It says in a few places that a list or vector
is "newly allocated", which appears to be OK.)

I suppose in future, it should be clarified that if, e.g., array-permute
is handed the identity permutation or array-translate is handed the zero
translation then the array argument can be returned unchanged.

> However, if we are talking about a revision of the
> SRFI (which I think is premature just now), it's also worth considering just
> removing the possibility of non-zero lower bounds, and/or extending the
> ranges to be non-contiguous.

I'm not considering a revised SRFI at the moment.

Maybe I'm not understanding correctly, but nonzero lower bounds are
useful for many algorithms and are part of other SRFIs (164, for
example).  So I think they should remain as an option in any revision of
this SRFI.

> Re: 5 my biggest question is, if we no longer have array-freeze!, how
> do we make immutable arrays?

There are currently many ways to make immutable arrays:

Procedure: make-array interval getter ;; no setter
Procedure: make-specialized-array-from-data data [ storage-class [
mutable? [ safe? ] ] ]
Procedure: array-copy array [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-copy! array [ storage-class [ mutable? [ safe? ] ] ]
Procedure: list->array interval list [ storage-class [ mutable? [ safe?
] ] ]
Procedure: list*->array d nested-list [ storage-class [ mutable? [ safe?
] ] ]
Procedure: vector->array interval vector [ storage-class [ mutable? [
safe? ] ] ]
Procedure: vector*->array d nested-vector [ storage-class [ mutable? [
safe? ] ] ]
Procedure: array-stack k arrays [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-stack! k arrays [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-decurry AofA [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-decurry! AofA [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-append k arrays [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-append! k arrays [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-block AofA [ storage-class [ mutable? [ safe? ] ] ]
Procedure: array-block! AofA [ storage-class [ mutable? [ safe? ] ] ]

I added array-freeze! as a helper procedure long before I exported it as
part of the SRFI.  I suspect that many implementers would use such a
procedure internally, but I don't see the need to export it.

> That doesn't mean, though, that there isn't some other way to solve the
> problem more efficiently.

Indeed, I'm thinking of some number-theoretic way of looking at it.

>  But either way I think the time and complexity
> would be enough that we should just state "it is an error" and not expect
> implementations to do the checking.
Yes (for now ;-).

Thanks for your comments.

Brad