[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bad things Re: Some thoughts...

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