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.
