S.H.M.J. Houben wrote on Mon, 2001 Nov 12:

> Interesting proposal.
>
> But of course lots of remarks:

Thanks. Sorry for the delay - you were so fast I was not on the list
myself yet, so I did not have your message at hand to follow up to.
(I did a lynx -dump to a *mail* buffer now.)

> 1. The functionality of multi-dimensional arrays can also be
>    provided by nested 1-dimensional arrays. It is unclear to me why
>    multi-dimensional arrays are needed at all.

I'm afraid ultimately they are not needed, but then one-dimensional
arrays are not ultimately needed either.

>    What is the motivation: efficiency (and if so, explain how the
>    proposal is more efficient)

The share-array magic provides a lot. A simple example: define a dot
product for one-dimensional arrays, and then apply it to rows and
columns of matrices. With vector-of-vectors, you have to copy each
column, if not each row. With truly shared arrays, you need not.

I have not timed anything, though.

>                                or added functionality (and if so,
>    give an example of things we can do with SRFI-25 not easily done
>    with R5RS vectors).

Look at the transpose in the "tools file" linked from the Examples
section. (Weird - netscape thinks it is "untyped binary data". All the
files are source code and contain only ASCII bytes.) It just permutes
the index list and accesses the original array.

> 2. I don't think array-dimensions is a good name. I would [...]
>    what about calling it array-number-of-dimensions ?

Too unwieldy. I'd rather call it haulong. What about array-dim? Or
array-rank again, though somebody used to oppose that (because matrix
rank is something else altogether).

> 3. I don't like the shape format. It is logically a list of pairs:
>    why not write it as one: e.g. ((0 4) (0 4)) looks better to me
>    than (0 4 0 4). For 0-based arrays the shorthand (4 4)
>    could then be used.

A list of pairs would be ((0 . 4) (0 . 4)), so there is already an
arbitrariness there. Yes, the bounds come logically in pairs, but I do
not agree about any particular data structure being logical. To really
write what the shape is I would write

    (cartesian-product
       (integers-between b0 e0)
       (integers-between b1 e1)
       ...).

Also, (shape 0 4 0 4) does not get more complicated when an individual
index expression gets more complicated. List structure would really
favour constant bounds. Compare

    (shape b (* 2 e) b (+ e 1))
    (list (list b (* 2 e)) (list b (+ e 1)))

and also notice that the very word "shape" there communicates intent
to the reader, while "list" does not.

> 4. Apparently arrays are supposed to be disjoint from vectors.
>    This could be made more explicit. Also, this means that even
>    1-dimensional 0-based arrays are disjoint from vectors?

Hm. Maybe that should be more explicit. Yes, I think they are best
disjoint. Array-ref and friends might be able to access vectors
transparently, with runtime cost, but I would not want to ask
implementors to make vector-ref and friends able to access certain
kinds of multidimensional arrays. They might just refuse.

> 5. From reading the proposal I understand that () is a valid shape,
>    but perhaps this point could be clarified separately.

No, a zero-times-two array is a valid shape, returned by (shape). It
is a natural limiting case, the shape of zero-dimensional arrays. I
have some text about that somewhere, but I do not think I want to
expand on it in the specification.

> 6. share-array says that a linear procedure must be given, and
>    that "a constant term is just a special case". Could it be that
>    "affine" is meant instead of "linear"?

You appear to be right. I will change that. My ignorance.

> 7. I would rename build-array to tabulate-array . There is little
>    difference, in my mind, between making and building an array.

I agree. Good names do not come for free. Thanks.

I will not bother the editors with that, though, as build-array is not
in the specification. It is currently an illustration only: the Issues
section is just for the discussion.

(Sigh. I exaggerated the number of times Brian Denney sent his mail
bomb. Sorry for that.)
--
Jussi