[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: constructor naming

This page is part of the web mail archives of SRFI 47 from before July 7th, 2015. The new archives for SRFI 47 contain all messages, not just those from before July 7th, 2015.



 | From: Taylor Campbell <campbell@xxxxxxxxxxxx>
 | 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 <agj@xxxxxxxxxxxx>
> Date: Sat, 29 Nov 2003 15:44:16 -0500 (EST)
> 
>  |     * Subject: compatibility
>  |     * From: Per Bothner <per@xxxxxxxxxxx>
>  |     * 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.