Re: constructor naming Aubrey Jaffer 05 Jan 2004 19:15 UTC
| From: Taylor Campbell <firstname.lastname@example.org> | 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 <email@example.com> > Date: Sat, 29 Nov 2003 15:44:16 -0500 (EST) > > | * Subject: compatibility > | * From: Per Bothner <firstname.lastname@example.org> > | * 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.