http://www.haskell.org/haskellwiki/APL
I'm glad someone is trying to think about expressing an Iverson Array in a language like Haskell. Though I think I would do things a bit differently than what they're doing. In J's implementation, an array is expressed as a data type tag and two lists. One is a list of integers (the shape of the array), and the other is the data (and the length of the data must match the product of the shape). In Haskell, the idea of using a data type tag would probably meet some resistance. One approach, though, would be to have a data list for each potential type tag (and only the one that matches the type tag could be non-empty). Another option for dealing with data types might be to have the array be a type class rather than a type. This perhaps better fits the "Haskell way of thinking" - it pushes some complexity into the code but I imagine that the Haskell community likes that kind of thing. (Not so great for implementing a J interpreter, but nice for native haskell code.) Of course that gets back to the design proposed on the haskell wiki. There, the number of dimensions is being thought of as a "type tag". That, I think, loses the utility of J, but sometimes utility is not useful. But pursuing this line of thought gets you into dependently typed languages, and I don't think Haskell is such a language. A final issue is that J arrays have been implemented using contiguous memory, which Haskell lists are traditionally implemented using discontiguous memory. I'd expect some significant performance problems here, on large arrays, but in some contexts the difference should improve timings (especially in "micromanage the data" coding styles - something that current J implementations are sluggish about). FYI, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
