On 12/16/18 5:54 AM, Sudarshan S Chawathe wrote:
> Here are some comments on SRFI 164, mostly of a very minor nature.

Thanks for your solid comments!  I uploaded my work draft to:
http://per.bothner.com/tmp/srfi-164.html
Arthur, I suggest holding off updating until I've had a chance to add a comparison
with srfi 122.

>    - 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.

Correct.  I changed 'should' to be in emphasis (italic) as in other places.
I could put an an explicit rfc-2119 link, or may be that could be implicit
to all SRFIs - or may be could replace it by "is recommended".  (The
latter has the advantage of being compatible with rfc-2119 link but is
reasonably clear without referencing rfc-2119.)

Arthur, what do you think?

>    - 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.)

Well, the specification does have multiple procedures for that,
though it does require you to use different procedures if the step is negative.

Should the 'end' be exclusive or inclusive?

The argument for the first argument to be 'end' is that one is more likely
to want to default the end rather than the.  With your proposal you have
to provide at least 2 arguments.  Though since that is only 2 extra characters,
perhaps it is worth it.

An earlier draft used keyword arguments - basically the same as Kawa,
with without the special bracket syntax:

    (range START by: STEP <: END)
    (range START >=: END)
etc.

Perhaps we could provide both a keyword-based API and one not requiring keywords.

>    - 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)

Maybe - though I don't care much for the word 'interval'.

>    - Array-shape, item 4: The second example uses Kawa syntax; for
>      consistency, it could also include the SRFI syntax as in item 3.

I don't see what you mean.  I see Kawa syntax, but only after the non-Kawa syntax.

>    - 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)

I believe you're right. Oops.

>    - 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.

Indeed, that should use vector-ref.

>    - 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.

Common Lisp uses "row-major" in the general sense:
http://clhs.lisp.se/Body/f_row_ma.htm

See also https://en.wikipedia.org/wiki/Row-_and_column-major_order

I added the following to the Specification part:

     [Row-major](http://clhs.lisp.se/Body/f_row_ma.htm) or lexicographic order means viewing all
     the array elements as a sequence, with the right-most index changing more frequently.
     The row-major index of an element is its position (starting with 0) when the elements are
     considered in row-major order.

Clearer phrasing would be welcome.

>    - 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.

I don't think we need to require that ranges are arrays, but we do want
to allow ranges as indexes in array-index-ref and other places.

The "Ranges sections says:

     It is convenient but not required that standard vector procedures such as vector-map
     be extended to work on ranges. In that case, vector-ref on a range should be the same as range-ref.

However, that is not quite the same as saying ranges are vectors.

>    - array-ref: The example uses Kawa syntax [2 3] for #(2 3).

Oops.  Fixed.

>    - array-index-ref: In the third paragraph, I think 'lowers bounds
>      is' should read 'lower bounds are'.

Fixed.

>    - 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?

If (define a2 (array-transform a1 a2-shape transform))
and a1 is mutable, then a2 is also mutable.
If element (array-ref a1 I) is modified then (array-ref a2 J) is
modified if (equal? I (transform J)), assuming J is valid for a2-shape.

It is possible that a change in a1 would not change a2 if there is no such J.

The paragraph before array-transform explains it.

I changed the description to:
     Accessing this new array is implemented by calling the transform function (which is T above)
I don't know if that helps make it clearer.

>
>    - array-transform: The example uses Kawa vector-ref syntax (ix 0),
>      etc.

Fixed.

>    - share-array: The second example uses f64vector from SRFIs 4 and
>      164, which could be mentioned just for completeness.

Ok.

>    - 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.

There seems to be a mix (even in other SRFIs).  I added an "also known as".

>    - 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.)

Added a definition.

>    - The link to Kawa in the first sentence of the Implementation
>      section is broken: '/orh' -> '.org'

Fixed.

>    - 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.

Will do.

>    - 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.

I'm leaning towards that position.  The #(r 2) form has the advantange of
being simple and compatible with the spirit of SRFI 25.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/