| From: Taylor Campbell <xxxxxx@evdev.ath.cx>
 | Date: Mon, 22 Dec 2003 17:07:43 -0500
 |
 | Why was the constructor renamed to CREATE-ARRAY?

So that it won't conflict with SRFI-25.

> From: Aubrey Jaffer <xxxxxx@alum.mit.edu>
> Date: Sat, 29 Nov 2003 15:44:16 -0500 (EST)
>
>  |     * Subject: compatibility
>  |     * From: Per Bothner <xxxxxx@bothner.com>
>  |     * Date: Wed, 12 Nov 2003 12:04:15 -0800
>  |
>  | 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.
>
> You have it backwards!  As the appended SRFI-25 message shows, it was
> their decision to be deliberately incompatible with SLIB and its
> installed base. ...

 | Everywhere else it's MAKE-foo: R5RS's MAKE-VECTOR & MAKE-STRING,
 | SRFI 1's MAKE-LIST, SRFI 25's MAKE-ARRAY, et cetera;

CREATE-ARRAY can create uniform arrays of various types.  The
procedures you mention do not; (MAKE-STRING can return char arrays
only).  MAKE-ARRAY is incompatable with the others in that its first
argument is not (necessarily) an integer.

 | I think that CREATE-ARRAY breaks a lot of consistency.

SRFI-47 array procedures have a different consistency:

        (create-array  proto        bound1 bound2 ...)
   (make-shared-array  array mapper bound1 bound2 ...)
          (array-set!  array obj    index1 index2 ...)
    (array-in-bounds?  array        index1 index2 ...)
           (array-ref  array        index1 index2 ...)

 | I didn't see any consensus on renaming on this mailing list,
 | either...

The only occurence of the word "consensus" in
http://srfi.schemers.org/srfi-process.html is:

  In particular, lack of a reference implementation (as defined above)
  is grounds for rejection. This can only occur if the ``reference
  implementation'' requirement is being met by an outlined
  implementation (type 5), and there is consensus that the
  implementation outline is not adequate. Note that this is never a
  permanent rejection, because creation of an implementation of one of
  the other types is a complete refutation of this basis for
  rejection.

Which doesn't apply to SRFI-47.