This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 contain all messages, not just those from before July 7th, 2015.
David Rush writes: > I have just scanned through the SRFI document and a fair bit of the > discussion. Just two quick thoughts. > > 1) (array-set! a dim0 dim1 ... dimn val) is a *really* bad specification > for this API. Yes, I know it's compatible with vector-set!, but > it's still not right. This form is deeply inefficient, requiring > list packaging of the dimensions (because of the variable length Any implementation of a variable number of arguments requires such packaging. Yours do, below. > argument list) *and* the value to be placed in the array is bundled > into the same data structure as the indicies. I suppose the first index could be left out. Then it's the same number of items in the bag as in number 1 below. Implementations need not copy the list again, to take the value out from the end. The reference implementation does not. In the worst case, if a user really is in a hurry and insists on using array-set! and building its argument lists dynamically and then using apply, they can stash the values to the end with set-car! to avoid any allocation. > either of the following is far better: > 1 (array-set! a val dim0 dim1 ... dimn) > 2 (array-set! a (array-index dim0 dim1 ... dimn) val) Both of these use variable length argument lists. The second would also create some package; to be as efficient as possible, the package should be the list that the variary mechanism of Scheme builds - just what array-set! does now but does not expose to the user. And you make the user call an extra procedure every time they want to pass a couple of indices to array-set!. > I like 2 because of symmetry with the array-shap concept. Also it > has the nice possibility of allowing assignments to larger units of > the underlying array than just single elements. I'm rather hoping that array-set! would not be the most common tool in practice. The latter case here seems more like an array thing already: treating an arrangement of values as a unit. > 2) The SRFI should be a completely abstract proposition. There are so > many different array implementations that might be desirable in a [...] > for production (I am specifically thinking of numerical & graph > applications here where sparse arrays/matrices can be very common). Hm. Could the sharing mechanism be useful with sparse arrays? Perhaps it could. I haven't thought of that at all. > This means that any vector/array equivalence is a *bad thing* IMO. > Preserve disjointness! -- Jussi