compatibility Per Bothner 12 Nov 2003 20:04 UTC

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:

  (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.


(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