SRFI 164 draft 3 comments Sudarshan S Chawathe (16 Dec 2018 13:54 UTC)
Re: SRFI 164 draft 3 comments Per Bothner (18 Dec 2018 02:08 UTC)
Re: SRFI 164 draft 3 comments Arthur A. Gleckler (18 Dec 2018 07:27 UTC)

SRFI 164 draft 3 comments Sudarshan S Chawathe 16 Dec 2018 13:54 UTC

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