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 John Cowan 16 Apr 2026 01:19 UTC

Lexical syntax is understood before macros are run, and macros can't
generate them.  The only way to produce new objects at the lexical
level is with `read`.

On Wed, Apr 15, 2026 at 8:21 PM Bradley Lucier <xxxxxx@purdue.edu> wrote:
>
> 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