While the SRFI process allows alternative and incompatible
implementations, a meta-goal is to define APIs that can be portable
across Scheme implementations. This new specification touches on
existing SRFIs 4 and 25, both of which have been implemented by a number
of Scheme systems. While in theory it may be possible to implement both
SRFIs 25 and 47 at the same time (by descriminating of the parameters to
make-array), that would be a fragile hack.
The new SRFI is deliberately incompatible with a prior SRFI, and one
that is implemented in multiple Scheme systems. It does not provide a
rationale for why we need an incompatible SRFI. It says it provides a
"richer set of features" than SRFI-25, but it does not explain why it
would be impossible or inferior to instead extend SRFI-25. It also says
the new SRFI has "more compatibility with Common-Lisp" but surely that
is secondary compared to compatibility with existing Scheme implementations.
An alternative (implemented in Kawa) is to allow the base array of
SRFI-24's share-array to be a uniform vector:
(share-array
(f64vector 1.0 2.0 3.0 4.0 5.0 6.0)
(shape 0 2 0 3)
(lambda (i j) (+ (* 2 i) j)))
This is may admittedly be a bit tedious, but we can provide an
alternative make-array that takes a "prototype" of some kind.
A simple and general prototype mechanism that does not require us to
define "types" and "prototypes" (but does not proclude a future SRFI
that does that) is to use procedures. I.e.
(make-array shape [object [prototype]])
where 'prototype' is a 2-argument procedure that creates a vector, using
it's first argument as the length and the second as the value.
The default for the prototype is make-vector.
So
(make-array (shape 0 2 0 3) 99 make-s32vector)
is equivalent to:
(share-array (make-s32vector 6 99) (shape 0 2 0 3)
(lambda (i j) (+ (* 2 i) j)))
If we later define "type specifiers" in a new SRFI, we can extend this:
(make-array (shape 0 2 0 3) 99 <sint32>) ;; or whatever
--
--Per Bothner
xxxxxx@bothner.com http://per.bothner.com/
