[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bad things Re: Some thoughts...
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
> 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!