It is actually not complicated at all if one just defines a function (let us call it matrix) that returns settable functions. Then one could write code like this
(let m (matrix '((1 0) (0 1)))
(= (m 0 1) 42))
Similar things could (and in my opinion: should) also be done for each, len, and other basic functions and macros to enable iterations through, and manipulation of, stateful functions.
It´s not so difficult as it looks: is is just a function that returns a function that returns a function. If you are used to object orientation, think of matrix as instansiation, m as an object, and the returned setter as a method. With the arc abbreviations, you could also write (m.settersym val 0 0) rather than having to modify =, but personally I would like to have some setter macro to make the syntax more natural (By the way: this is exactly how you would do a matrix implmentation in C++, only with templates in stead of macros)
^^ Again, somebody has to write the nastiness ^^. The main difficulty really is the fact that you have a polymorphic function that dispatches based on number of parameters as well as their contents.
Although I suppose you could actually use --warning-blatant-self-proclamation-- my p-m: macro:
(p-m:def matrix
(,(s (is s settersym)))
writerfunction
(i j)
(readerfunction i j)
x (err "argument error"))
The = macro looks into a database of settable functions and there is no way to update the database at array creation. In order to use = I must either change let, with, and withs, or, introduce settable accessors, such as aref, but as I said, accesssors are not nice (I use arrays a lot in common lisp, and the accessors are driving me mad). The <- is actually a lot more general than =; it can set anything that returns its own setter, not just arrays. It is not suited for hash-tables, though, since they are likely to contain the key Xsetter.
Actually, with only a tiny modification of the core code and using tagging as a typing mechanism, you can set this sort of array in more or less the same way you set hashes:
; Added as line 454 of ac.scm:
((ar-tagged? fn) (ar-apply (ar-rep fn) args))
; Added to arc.arc
(let old sref
(def sref (com val ind)
(if (no (isa com 'array)) (old com val ind)
((com 'setter) val ind))))
; Added at the end of your array code (or directly to make-array-wrapper)
(let old make-array-wrapper
(def make-array-wrapper (dim store)
(annotate 'array (old dim store))))
If you don't want to patch that manually, I've added your array lib and my patches to the Anarkies.
Patches are not a good thing since they breake the fundamental idea of arc: a language implmented in itself. Also you will soon run into trouble when introducing other array types, such are diagonal, bi-diagonal, tri-diagonal, upper-triangular, etc, and not to talk of foreign arrays, all requiring a new patch. (I can think 100 different array types, it should not require 100 patches.) However, it might be that a solution is to improve the arc type system itself, which seems over-simplified.
I disagree. If by "patch" you mean modifying the behavior of sref via Arc code, I think that's very much in tune with the fundamental principles of arc. I also think that working from basic principles - type, rep, and annotate (nee tag) - is a much more Arc-ish way to make a type system than having something deep and complex built in.
As for defining new accessors for every new type, it would be easy to modify sref to do a table like = does, and make defining accessors as easy as defset is now.
I think we need to do both, both spawn functionality based on types, but also build more complex constructs at the the top of the simpler.
The = and the <- do different things, the = depends on type, <- is a lot more general and depends on what the object itself returns. Arrays are higher order objects, and they depend on element-type, indexing, and, the physical store (currently only hash tables, but it should be raw memory segments for fast arrays) . So the true "type" of the array is a tuple of three (when i said 100 types I though about all the combinations. In reality there are infinitely many, but most them are not needed). In reality what I do in the library is to make a lexical type, that is created with the object, and is thrown away when its not needed anymore. However, a third possibility, is to make something like a template system. This is not easily done in CL, but should be possible in arc due to first class macros. How to actually do this, I do not know.
