Final discussions Bradley Lucier (11 Apr 2022 22:49 UTC)
Re: Final discussions Alex Shinn (22 Apr 2022 08:55 UTC)
Re: Final discussions Bradley Lucier (05 May 2022 15:26 UTC)
Re: Final discussions Alex Shinn (05 May 2022 21:35 UTC)
Re: Final discussions Bradley Lucier (26 May 2022 18:52 UTC)
Re: Final discussions Alex Shinn (29 May 2022 20:59 UTC)

Re: Final discussions Bradley Lucier 05 May 2022 15:25 UTC

On 4/22/22 4:55 AM, Alex Shinn wrote:
> On Tue, Apr 12, 2022 at 7:49 AM Bradley Lucier <xxxxxx@math.purdue.edu
> <mailto:xxxxxx@math.purdue.edu>> wrote:
>
>     Dear Colleagues:
>
>     I can't think of anything to improve about this array SRFI, so without
>     further feedback I'm OK with finalizing it, but I'd like to mention
>     previous comments that are, to my mind, as yet unresolved;
>
>     1.  A better name for array-elements-in-order?.
>
>
> I prefer my earlier suggestions of either array-indices-in-order? or
> array-contiguous-and-in-order?, but am open to other suggestions.

The name that I think best fits the concept is

array-elements-stored-contiguously-with-increasing-index?

and I think that each of the three names above doesn't quite capture the
precise concept, and I don't see anything to prefer one of the three
over the others.

> Another naming issue - index-first/last/rotate return permutations, and
> neither take nor return multi-indices.  Is there a better name?

I like the names, I think once you know what the general idea is, each
captures precisely the meaning.

>
>     2.  Syntax support for comprehensions.
>
>
> I think it's best to leave these as a future extension since there many
> approaches to comprehensions.  This can be implemented portably, but if
> you want to provide easier building blocks consider an interval-cursor API:
>
> * (interval-cursor domain) - returns a cursor pointing to the first
> multi-index in domain
> * (interval-cursor-get ivc) - gets the current multi-index of the cursor
> * (interval-cursor-next ivc) - returns a cursor pointing to the
> lexicographic next multi-index, or #f if at the end
> * (interval-cursor-next! ivc) - linear update variant

I don't think I'm going to pursue comprehensions or cursors.

>
>     3.  multi-array fold: array-foldl and array-foldr take only a single
>     array argument.
>
>
> And yet array-map and array-for-each take multiple arrays.  Can we just
> make this consistent and support multiple arrays in the folds as well?

These are now in

https://github.com/gambiteer/srfi-231/tree/weird-domains

They're pretty ugly (and slower) than array-map (a simple manipulation
of array getters) and array-for-each (based simply on interval-for-each)
because I want to implement them in terms of %%interval-fold.

Please see if you agree with the semantics/documentation/testing/...

Brad