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.