Jussi Piitulainen <xxxxxx@ling.helsinki.fi> writes:
> Brad Lucier writes:
> > This is a side comment about this SRFI.

> > So I looked at Alan Bawden's code and this SRFI.  And it turns out
> > that neither is at a high enough abstraction level to really
> > simplify my life.

> They are essentially the same.

Well, sort of. I think that my biggest problem is with
make-array. However, I don't think there's a real issue here.

> I think I have a good answer to your concern about working at the
> level of individual elements. The answer is that these operations are
> just the primitives that should be used to write the higher level
> operations.

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.

> > 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

The mutability assumtption is present, and it worries me. However, it
doesn't worrk me that much because I'm looking for a
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. However, I *can* use the SRFI array spec in the
meantime to test my algorithms on small datasets.

The type-safety issue is built in to Scheme. If you're not going to
drive safely, you'd better not get into this car. I just don't see any
other way around it...

> The next question will be whether to finalize or withdraw.

Yes, that is a next question.

david rush
--
The important thing is victory, not persistence.
	-- the Silicon Valley Tarot