Aubrey Jaffer wrote:
> This works by the implementation knowing the difference between
> SRFI-25 arrays and SRFI-63 arrays.  This difference can be hidden
> entirely from the user.

Not sanely.

> I claim that SRFI-25 and SRFI-63 can coexist -- not that they
> interoperate!

Having two different array implementations, with the same
functionality, in the same Scheme implementation, using overlapping
but inconsistent function names is out of the question.

I really don't want to add a "this array was allocated using srfi-63
make-array" bit to my arrays.  That's utterly gross.  And of course
it doesn't work to have vectors be both SRFI-25 and SRFI-63 arrays.

The only sane way to support both SRFI-25 and SRFI-67 is to have them
be in separate *optional* modules:
(require 'srfi-67) ;; if you want SRFI-67 arrays.
(require 'srfi-25) ;; if you want SRFI-25 arrays.
Unfortunately, this causes probelems with any implementation
that provides either set of functions in the default environment.
(require 'srfi-67) must disable the srfi-25 names and vice versa.
Existing code that uses srfi-25 array-set! will silently break
if you (require 'srfi-67).  If you have multiple modules, things
are really messy, unless you have a real module system.

>  | This is a recipe for disaster.
>  |
>  | STFI-25:
>  | (array-set! array k ... obj)
>  | (array-set! array index obj)
>  | SRFI-63:
>  | (array-set! array obj k1 ...)
>  |
>  | It is claimed that "Type dispatch on the first argument to
>  | array-set!  could support both SRFIs simultaneously."  I don't
>  | believe that.
>  | How would you handle:
>  | (define array (vector 'a 'b))
>  | (set! array 1 0)
Note: this should have been: (array-set! array 1 0)
>  | Is the result #(a 0) or #(1 b)?
>
> SRFI-25 says:
>
>   It is not required that vectors not be arrays.  It is not required
>   that they be, either.
>
> For your example to be ambiguous, you would be depending on
> unspecified behavior of SRFI-25.

Irrelevant to my point.  I used a vector for convenience - the same
issue arises with a rank-1 array.  And for that matter higher-rank
arrays, but I chose a simple example for illustration.

In any case, in my implementation, vectors are arrays.  The disclaimer
is to allow implementating arrays without modifying the core language.
If you have the option to tweak the langauge coret, clearly it is
better if vectors *are* rank-1 arrays.  It's a quality-of-implementation
issue.

> But vectors are mandated to be arrays in SRFI-63.  So the result of
> your example would be #(1 b).

Not in my implementation.  The result *is* #(a 0).

> By vectors being SRFI-63 arrays, not SRFI-25 arrays;

But vectors *are* SRFI-25 arrays in some existing implementations.

> and by the
> implementation knowing the difference between SRFI-25 arrays and
> SRFI-63 arrays,

Unacceptable.  And doesn't work if vectors are also SRFI-25 arrays.

> Bawden arrays predate SRFI-25 by a decade.  SRFI-25 should have chosen
> other names.

Was that issue brought up during the discussion of SRFI-25?
If not, it's irrelevant.  You cannot expect everyone to know
every possible array package.  The fact that it was part of SLIB
is more relevant: that should have been discussed, at least.
(One problem I see with SLIB is that it contains multiple alternative
APIs and implementations of the same basic concept - e.g. macros.
That makes it harder to use it as a source for "best practices"
or "standarization".)

There is a pragmatic issue: How much currently-used code uses
Bawden's/SLIB's arrays vs how much uses SRFI-25's.  That's hard to
tell, but perhaps there is some data or indicators.  Without that,
the default for a SRFI should be that compatibility with a past SRFI
(and one supported by multiple active/popular Scheme implementations)
should weigh more than conflicting non-SRFI APIs.

 From the SRFI document:
   To my knowledge, shared arrays were original to Alan Bawden in his
   "array.scm".

I doubt it, unless you're restricting yourself to Scheme.
Certainly the concept predates 1993 by far.  There are precursurs in
APL and Fortran going back to the 60-ies.  I had it in my Q language
from the 80-ies/early 90-ies.  (The latest "modify" dates on Q are
1994, but most of the work came before that.)
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/