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.
Noel Welsh writes: > Sorry it's taken me so long to respond. I've been > trying to read up on mathematics of arrays (mostly > unsuccessfully) so that I might have more intelligent > things to say. No rush. There's a week gone from the mandated sixty days which can be extended to ninety if need be. >> 1) modarray single element case in Scheme would _be_ >> array-set!, not make it redundant; > > Not quite. modarray is functional in SAC. It returns > a new array. Ah. Oh yes - SAC does not provide array-set! at all? > I think there needs to be something to get all the > data from the array. Maybe > > (flatten array) -> vector > > Gets the data part of an array in row-major order. That would be precisely Kelsey's (array->vector arr). This might go into this SRFI. >> 4) there is no way around Scheme being an imperative >> language with runtime typing; static compiler >> optimisations are not in reach, nor is >> anything restricted to single assignment. > > Hmmm...I don't want to start a bun-fight here. Let's not - I don't even know what a bun-fight is. Cobuild 2nd edition did not help. I don't know much about compilation techniques, so my intuitions here are not worth much. However, if you are thinking of things like Steele's original compiler, isn't it just so that those compilers know a lot of a few things: lambda, procedure call, if, set!, and that's it? Perhaps such analysis could be done for arrays. It would require tight integration and a lot of work. Maybe some implementor would be inspired to do the research. Other implementors would either just drop the portable array library in or decide that its integration is too much work. I wish to keep it so that they can do the former and have something useful. (Let them work on more fundamental things like procedure calls and concurrency.) > A few more issues: > > I think the basic procedures should all work on > vectors as arguments. E.g. instead of > > (array-ref array x1 x2 ...) > > I'd vouch for > > (array-ref array index-vector) > > Why? To preserve symmetry. With functions returning > lists there is the nice symmetry that those results > can be immediately applied as the arguments to another > function. No such symmetry exists with array-ref as > it currently stands. I see what you mean ... This magic is in apply ... There is a lot in Scheme where lists work and vectors don't ... Not an easy issue. I hope to keep simple access simple, so that one need not write the code to allocate a data structure just to access a single array element. > You can't, e.g., get an array > slice representing an index and then apply that to > array-ref. Is this is a very common thing to do, in practice? You can do (apply array-ref arr1 (array->list arr0)), assuming an analogue to (array->vector arr). Or there could be something like (apply/array array-ref arr1 arr0). If I put array->vector in, I might put array->list in at the same time. They are conceptually the same thing, so it is just a couple more lines in the specification. > I also think there is a need for a simple array slice > primitive (equivalent to the psi function in SAC). > The provided function, though expressive, is complex > and makes writing simple array slices unduly > difficult. There is a tension between keeping primitives primitive and making them as easy to use as possible. In this case, I would put easier variants in a higher level library, just like lambda is primitive syntax and let is derived. One thing we could do is to provide a small (or large) higher level library as an appendix. It could later be a basis for a further SRFI (maybe called "The Rest of APL"), assuming the current one gets adopted. We are already building an archive of relevant discussion and references on related work. By the way, some of those additions might only abstract on the affine map, not on share-array itself. One wants to do a right thing. -- Jussi