![](https://secure.gravatar.com/avatar/13663028cac36d0b9ff102354f298263.jpg?s=120&d=mm&r=g)
On Fri, Apr 11, 2008 at 10:26:41AM -0400, Liam Healy wrote:
Tamas,
I like your ideas on general array views, it seems very standard; I think what we're all talking about is array slicing http://en.wikipedia.org/wiki/Array_slicing. I understand and support
Liam, It seems that my idea is more general. With affine maps, you can do index rearrangements (eg reorder rows/columns in reverse order) and lot of other fancy stuff.
the desire to take advantage of everything Lisp has to offer, however, I would like to maintain compatibility with GSL and other foreign code to the extent possible where there is an analogous concept implemented, so we can take advantage of their functions (that's the idea behind GSLL after all). It seems to me that FFA should work just fine. Perhaps Zach can confirm that GSL's views work the way I expect in matching your general array views description, then your scheme should map into GSL's views. I think your general array views will give CL access to an underlying "full" array, and GSL's view can be made to match, and FFA can provide the option that the underlying full array is one and the same (on SBCL) or properly copied (everywhere else).
Currently, the affine maps are not in FFA, but it appears that views in GSL need them. If you need affine maps, let me know, I can whip up something on top of the current FFA (so even with these very general arrays, one could always access the underlying Lisp array if needed, I consider that an advantage).
As far as the aref issue goes, I don't see it as a problem. I currently define #'maref which could be used as is, or #'aref could be shadowed out of the CL package if the user desires. You could even do this in CL code written by someone else by putting the shadow in the package definition.
Indeed you can shadow aref. But code that assumes that some variable is a Lisp array when it is not could get into trouble by other ways, eg using row-major-aref, displacing it, etc. I would prefer if the fancy array type with affine mapping were kept separate. I understand to desire to provide the whole interface to GSL, but in my opinion, implementing views is not central for Lisp users and leads to more confusion than it is worth. For the moment, I would suggest that we think about views more carefully, write a toy implementation that on top of ffa and try to see what the issues are. Because Lisp arrays and affine mapping arrays are separate things, what GSLL functions accept and return is also an issue. I could have a matrix that is a Lisp array, or a matrix that is a slice from the middle of another matrix. But to me it is just a matrix, so I would expect to call the same function to deal with it. I think some OO glue could deal with this, but I don't know what functions are involved. Tamas