Here are some comments on SRFI 164, mostly of a very minor nature.
- Reference Draft #3 published: 2018/12/7.
- The second paragraph of the Specification section notes:
A library-based implementation of this specification should use
the existing (generalized) vector type for "simple" rank-1
zero-lower-bound arrays (not created by share-array).
I assume that the "should" here meant in RFC-2119 sense. That
is, is the above merely a suggestion/recommendation, and not a
hard requirement.
- Ranges: Given the variety of constructors, it seems a bit odd to
not also have a built-in way to create a range based on a start,
end, and optional step. Perhaps it is a Pythonism, but it seems
natural enough to me.
(range 3 17 4) => (3 7 11 15)
(Of course, it can be defined easily using range-take or iota.)
- Array-shape: Given the many alternatives for specifying shape
here, does it also make sense to include something similar to the
interval procedure of SRFI 122?
(interval lower-bounds upper-bounds)
- Array-shape, item 4: The second example uses Kawa syntax; for
consistency, it could also include the SRFI syntax as in item 3.
- In the stated equivalence for (apply shape bounds), shouldn't the
elements of the vector be reversed, as follows?
(apply array
(vector (/ (length bounds) 2))
2
bounds)
- In build-array: I think the example uses Kawa syntax (ind i) for
(vector-ref ind i). I noticed later the section on "Array as
procedure (non-normative" which may cover this point.
- In index-array, and few other places: Should "row-major" be
replaced with something more general (for arbitrary number of
dimensions, not just 2)? I suppose the generalization is obvious,
but something like "lexicographic" could be substituted.
- In index-array: The mentioned equivalence implies that ranges are
arrays. I think this would follow from ranges being vectors
(required?) and vectors being arrays but it was not clear to me.
These things are probably mentioned somewhere but perhaps are
worth emphasizing.
- array-ref: The example uses Kawa syntax [2 3] for #(2 3).
- array-index-ref: In the third paragraph, I think 'lowers bounds
is' should read 'lower bounds are'.
- array-transform: I do not understand when modifying a1 will
result in a2 being modified. Is it simply unspecified or is there
some property of the transform function that determines this?
- array-transform: The example uses Kawa vector-ref syntax (ix 0),
etc.
- share-array: The second example uses f64vector from SRFIs 4 and
164, which could be mentioned just for completeness.
- I think this SRFI uses "uniform" to refer to what some related
prior SRFIs call "homogeneous". Not a big deal except that
"homogeneous" is useful for searching for the earlier ones on the
Web site.
- array->vector: I think "simple" arrays are defined only in passing
early in the Specification (2nd paragraph), apart from mentions in
the Implementation section. It would be good to define them
independently to be a bit more prominent. (I missed it at first.)
- The link to Kawa in the first sentence of the Implementation
section is broken: '/orh' -> '.org'
- It would be very useful to describe the key differences between
this SRFI and SRFI-122, perhaps in the Rationale section. If
low-level differences are too many to enumerate then high-level
design differences may suffice, at least for a while.
- I agree with the comment that Ranges should be moved to a separate
SRFI.
- Re. the item for shape-specifiers in Issues: I wonder if it makes
sense to define one of the many shape kinds (say, the #(r 2) one)
as a preferred/canonical one, with the others defined by mapping
to that kind. Then that one could be returned by an array-shape
procedure and it may make understanding shape specifications a bit
easier too.
Regards,
-chaw