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