David Rush writes:
> Jussi Piitulainen writes:
>> Brad Lucier writes:
[...]
> No bother. Olin Shivers spoiled us all with SRFI-1. The combinator
> work *needs* to be done, though. If not in this SRFI, then in a
> rapidly appearing follow-on.

Let us see this SRFI to some conclusion first.

>>> Both assume that there are underlying arrays that are mutable, you
>>> can set! elements of the arrays, the underlying arrays are generic
>>> containers (vectors, not f64vectors or f32vectors, ...), etc.
>
> I don't see this depth of assumptions. Brad seems to be bringing up
> two orthogonal issues:
>
>         1) mutability
>         2) type-safety

I thought people want restricted vector types for space efficiency,
rather than type safety.

> categorically-standard spec. Err...internal jargon that: I'm looking
> for a spec that I can plug-n-play alternate implementations for
> specific problems. e.g. I'm working (low prio) on some large, sparse
> matrix code for doing latent semantic indexing tricks. My arrays are
> *not* going to be writable, but I don't care much because I won't be
> writing to them.

This is definitely interesting. Perhaps it would be better to separate
index arithmetic from backing vectors entirely? The nature of the
package would change rather a lot - quite possibly to the better.

Where do your sparse matrices come from if not from something like
make-array?
--
Jussi