Noel Welsh writes:

> Sorry it's taken me so long to respond. I've been
> trying to read up on mathematics of arrays (mostly
> unsuccessfully) so that I might have more intelligent
> things to say.

No rush. There's a week gone from the mandated sixty days
which can be extended to ninety if need be.

>> 1) modarray single element case in Scheme would _be_
>>    array-set!, not make it redundant;
>
> Not quite.  modarray is functional in SAC.  It returns
> a new array.

Ah. Oh yes - SAC does not provide array-set! at all?

> I think there needs to be something to get all the
> data from the array.  Maybe
>
>   (flatten array) -> vector
>
> Gets the data part of an array in row-major order.

That would be precisely Kelsey's (array->vector arr).
This might go into this SRFI.

>> 4) there is no way around Scheme being an imperative
>>    language with runtime typing; static compiler
>>    optimisations are not in reach, nor is
>>    anything restricted to single assignment.
>
> Hmmm...I don't want to start a bun-fight here.

Let's not - I don't even know what a bun-fight is.
Cobuild 2nd edition did not help.

I don't know much about compilation techniques, so my
intuitions here are not worth much. However, if you are
thinking of things like Steele's original compiler, isn't
it just so that those compilers know a lot of a few
things: lambda, procedure call, if, set!, and that's it?

Perhaps such analysis could be done for arrays. It would
require tight integration and a lot of work. Maybe some
implementor would be inspired to do the research.

Other implementors would either just drop the portable
array library in or decide that its integration is too
much work. I wish to keep it so that they can do the
former and have something useful. (Let them work on more
fundamental things like procedure calls and concurrency.)

> A few more issues:
>
> I think the basic procedures should all work on
> vectors as arguments.  E.g. instead of
>
>    (array-ref array x1 x2 ...)
>
> I'd vouch for
>
>    (array-ref array index-vector)
>
> Why?  To preserve symmetry.  With functions returning
> lists there is the nice symmetry that those results
> can be immediately applied as the arguments to another
> function.  No such symmetry exists with array-ref as
> it currently stands.

I see what you mean ... This magic is in apply ... There
is a lot in Scheme where lists work and vectors don't ...
Not an easy issue.

I hope to keep simple access simple, so that one need not
write the code to allocate a data structure just to access
a single array element.

>                       You can't, e.g., get an array
> slice representing an index and then apply that to
> array-ref.

Is this is a very common thing to do, in practice?

You can do (apply array-ref arr1 (array->list arr0)),
assuming an analogue to (array->vector arr). Or there
could be something like (apply/array array-ref arr1 arr0).

If I put array->vector in, I might put array->list in at
the same time. They are conceptually the same thing, so it
is just a couple more lines in the specification.

> I also think there is a need for a simple array slice
> primitive (equivalent to the psi function in SAC).
> The provided function, though expressive, is complex
> and makes writing simple array slices unduly
> difficult.

There is a tension between keeping primitives primitive
and making them as easy to use as possible. In this case,
I would put easier variants in a higher level library,
just like lambda is primitive syntax and let is derived.

One thing we could do is to provide a small (or large)
higher level library as an appendix. It could later be a
basis for a further SRFI (maybe called "The Rest of APL"),
assuming the current one gets adopted. We are already
building an archive of relevant discussion and references
on related work.

By the way, some of those additions might only abstract on
the affine map, not on share-array itself. One wants to do
a right thing.
--
Jussi