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.
| Date: Tue, 25 Nov 2003 16:49:51 -0500 | From: Taylor Campbell <campbell@xxxxxxxxxxxx> | | On Thursday, Nov 20, 2003, at 18:56 US/Eastern, Aubrey Jaffer wrote: | | > I will remove the read syntax from SRFI-47, which removes many of | > the objections. | | Why not provide SRFI 10 reader constructors? This kind of thing is | _exactly_ what SRFI 10 is for! Array syntax can be the subject of its own SRFI. | Also, I don't think my other questions, those not regarding reader | syntax, were addressed: will there be a follow-up complete array | library to deprecate SRFI 43 and some of SRFI 13? SRFI-43 contains many procedures which do not generalize to rank 2 and higher arrays. So an array-based SRFI would not replace SRFI-43. SLIB's array-for-each module defines: - Procedure: array-map! array0 proc array1 ... - Function: array-map prototype proc array1 array2 ... - Function: array-for-each proc array0 ... - Function: array-indexes array - Procedure: array-index-map! array proc - Procedure: array-copy! source destination The argument order to array-copy! seems inconsistent with the others. Sequence order is an essential idea in SRFI-13 (and for many functions in SRFI-43). Defining procedures which make sense only for rank-1 arrays in a multidimensional array package is poor practice. One might consider a rank-2 array of characters to be text on a page. I am unaware of Unicode or other character standards covering such constructs. But with most Schemes still limited to single byte characters, we need to resolve the plethora of difficult string issues before going where none have gone before. | and ARRAY=? is less general than it could be: why isn't it more | like SRFI 1's LIST= or SRFI 43's VECTOR= ? ARRAY=? was added to facilitate incorporation of arrays into EQUAL? A more complete solution would be to redefine EQUAL? instead. | I have also come up with another question: why is there no ARRAY, | analogous to VECTOR as MAKE-ARRAY is analogous to MAKE-VECTOR? VECTOR and STRING return arrays. The VECTOR, LIST, and STRING functions allow one to construct those objects on the basis of arguments alone -- not requiring explicit construction of intermediate lists. This property was important to some of the rrrs-authors; they did not want argument vectors to necessarily be lists. To do the same for arrays would require the dimensions of the array be passed as arguments to the ARRAY function. Passing them without using a list or vector would have them as several arguments. But there are a variable number of them, so the rank must also be an argument. This results in a form reminiscent of run-length coding: - Function: array prototype j k0 ... k{j-1} obj0 ... J should be an exact nonnegative integer specifying the rank of the array. K0 ... K{J-1} should be exact nonnegative integers specifying the dimensions of the array. OBJ0 ... should be (* K0 ... K{J-1}) elements to be stored in the new array in row-major order. `Array' returns a newly allocated array of type PROTOTYPE whose elements contain the given OBJ0 ... arguments. I can think of no Scheme precedent for having a variable number of (dimension) arguments followed by a variable number of other arguments; but it is well-defined. The lack of list or other structure to organize the obj0 .. arguments would probably make the ARRAY function difficult to use for all but the smallest arrays, but it could be useful for those. The prototype functions already generate one and zero element arrays. SCM has a function list->uniform-array which organizes the elements using lists (which should be renamed list->array): - Function: list->array rank prot lst Returns a uniform array of the type indicated by prototype PROT with elements the same as those of LST. Elements must be of the appropriate type, no coercions are done. In, for example, the case of a rank-2 array, LST must be a list of lists, all of the same length. The length of LST will be the first dimension of the result array, and the length of each element the second dimension. If RANK is zero, LST, which need not be a list, is the single element of the returned array. Which of these approaches makes the most sense?