[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Not quite enough abstraction
Jussi Piitulainen <jpiitula@xxxxxxxxxxxxxxxx> 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
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:
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.
The important thing is victory, not persistence.
-- the Silicon Valley Tarot