[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: constructor naming
| 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,
The only occurence of the word "consensus" in
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
Which doesn't apply to SRFI-47.