Re: A specifier for array dimensions in a followup to SRFI 231
John Cowan 14 Apr 2026 19:13 UTC
I am absolutely in favor of this. But it makes me wonder if we should
abolish the interval datatype altogether in favor of specifiers alone.
On Tue, Apr 14, 2026 at 2:59 PM Bradley Lucier <xxxxxx@purdue.edu> wrote:
>
> On 3/31/26 12:42, Bradley J Lucier wrote:
> > I’m trying to polish the rough edges of SRFI 231, and instead of, e.g.,
> >
> > (make-interval ‘#(0 3 0) ‘#(4 6 2))
> >
> > with the lower bounds ‘#(0 3 0) and upper bounds ‘#(4 6 2) where an interval argument is required, I plan to allow
> >
> > ‘#(4 (3 6) 2)
> >
> > Currently, I’m calling this an interval “specifier”.
> This commit:
>
> https://github.com/gambiteer/srfi-231/commit/2f21342a8e95a7c3ca65e547c6a4ba508aa6ac7d
>
> adds the routines
>
> interval-specifier?
> interval->specifier
>
> and extends the one-argument version of make-interval to accept an array
> specifier instead of just a vector of upper bounds; this is a
> backward-compatible change. (One might think of a procedure
> specifier->interval, but that's just make-interval.)
>
> The next commit:
>
> https://github.com/gambiteer/srfi-231/commit/ff2987615bcee795367fd7b0d263324116a4ae75
>
> uses the new specifiers in a couple examples where it seemed appropriate.
>
> I'd like to extend the array-* procedures that take intervals as
> arguments to additionally allow interval specifiers as arguments. I see
> these procedures as prospects:
>
> (make-array interval getter #\[ setter #\])
> (make-specialized-array interval #\[ storage-class #\[ initial-value #\]
> #\])
> (specialized-array-share array new-domain new-domain->old-domain)
> (array-extract array interval)
> (array-broadcast array new-domain)
> (list->array interval list #\[ storage-class #\[ mutable? #\] #\])
> (vector->array interval vector #\[ storage-class #\[ mutable? #\] #\])
> (specialized-array-reshape array interval #\[ copy-on-failure? #f #\])
>
> There are many interval-* procedures that take intervals as arguments,
> but it doesn't make sense to me to extend them to allow interval
> specifiers as arguments: If you write down the specifiers explicitly you
> often can just read off the procedure results, these procedures are used
> when you *don't* have a literal specification of an interval.
>
> Any comments before I proceed?
>
> Brad