syntax for inferred upper bound Peter McGoron (15 Apr 2026 11:37 UTC)
Re: syntax for inferred upper bound Wolfgang Corcoran-Mathe (15 Apr 2026 15:55 UTC)
Re: syntax for inferred upper bound Peter McGoron (15 Apr 2026 16:31 UTC)
Re: syntax for inferred upper bound Artyom Bologov (15 Apr 2026 23:21 UTC)
Re: syntax for inferred upper bound Bradley Lucier (16 Apr 2026 00:21 UTC)
Re: syntax for inferred upper bound John Cowan (16 Apr 2026 01:19 UTC)
Re: syntax for inferred upper bound Bradley Lucier (16 Apr 2026 01:27 UTC)

Re: syntax for inferred upper bound Bradley Lucier 16 Apr 2026 00:21 UTC

Based on my experience with SRFI 231, I'm going to make a suggestion.
Perhaps it will be helpful.

SRFI 231 has

(list*->array d nested-list #\[ storage-class #\[ mutable? #\] #\])

where only the dimension d is given, all lower bounds are zero, and the
upper bounds are inferred from the structure of the nested list.  This
has some limitations for certain empty arrays, there is no nested list
that can specify an empty array with domain

(make-interval '#(0 2))

because the inverse operation, array->list*, returns

(array->list* (make-array (make-interval '#(0 0)) error)) => '()
(array->list* (make-array (make-interval '#(2 0)) error)) => '(() ())
(array->list* (make-array (make-interval '#(0 2)) error)) => '()

so (list*->array 2 '()) always returns (make-array (make-interval '#(0
0)) error), never (make-array (make-interval '#(0 2)) error).

SRFI 231 also has

(list->array interval list #\[ storage-class #\[ mutable? #\] #\])

Here one specifies the interval completely, and the input is a list of
array elements, not a nested list.  So

(list->array (make-interval '#(0 2)) '())

has no problem returning (make-array (make-interval '#(0 2)) error).

The early notation in this SRFI, in trying to mimic Common Lisp, had the
same limitations as SRFI 231 list*->array, in that some (empty) arrays
cannot be specified.  My understanding is that the recent notation added
the explicit specification of the domain of the array, as in SRFI 231
list->array, to get around this limitation.

So, my suggestion:  Allow two options for specifying the domain of the
array:

1.  A nonnegative exact integer, which specifies the dimension, and the
entire structure of the array is taken from the nested list, with all
lower bounds zero.

2.  A specification of the complete domain of the array, compatible with
the nested list containing elements, but here the lower bounds don't
have to be zero, and the upper bounds have to agree with the result one
gets from interpreting the structured list.

Option 1 would seem to allow Peter's application in a straightforward way.

Brad