Paul Hudak writes, as long ago as August 6th: >Of course, what we REALLY need is a rich enough overloading mechanism >to allow using the same syntax to support arrays, lists, etc. Some >people I know are working on that... Well, we at Intermetrics have been working on incorporating Haskell into a hardware description language for the description of microwave hardware (MHDL) for about a year now. I have not been able to post to this list as I would like; I hope to try to do more of that in the near future. On this one subject, I think I have something to say. As a preface: this is not primarily a format issue (although, I admit, that I started thinking about this issue when the microwave engineers rose up en masse and smote me about the head and shoulders for the use of the "!" operator for array subscription). It is also the result of eighteen months worth of Al Gilman (local to our office) trying to pound into my head the importance of viewing arrays, and tables, as alternative mechanisms of defining functions. Credit where credit is due: thanks, Al! I submit (for everyone's consideration) that arrays should not be distinct from functions; indeed, that an array is an alternative mechanism for defining a function. "Indexing" an array is an artifact of the Fortran mechanism of viewing an array. An array should be evaluated just as a function is evaluated. I further submit (IMHO) that this definition is much closer to the normal definition of what a function is. My first abstract algebra class defined a function as a set of ordered pairs, and the first examples were lists of ordered pairs. The only mechanism that Haskell allows for the moment to reproduce this definition is a very large case statement (that I can think of: any corrections?). I think this is a mistake. We should be able to define a function by listing the ordered pairs in the function: i.e., by providing an association list. I also think this view of arrays would require very little change to the language itself. For example: array :: (Ix a) => (a,a) -> [Assoc a b] -> a -> b bounds :: (Ix a) => (a -> b) -> (a,a) indices:: (Ix a) => (a -> b) -> [a] indices = range . bound -- Still!!! elems :: (Ix a) => (a -> b) -> [b] elems a = [a i | i <- indices a] and so on. The only problematic element here is the bounds function. I submit that this is a natural function to apply to _any_ function whose first argument is constrained by (Ix a). Indeed, I would like to consider this in the light of the broader discussion concerning subtypes. The bounds function makes sense on any constrained domain for a function (and should diverge if that constraint does not make sense, as for unconstrained floats). Of course, this is simply the expedient of making the array function equal to the function in the MkArray definition. The MkArray definition has the bounds explicitly in the data structure (as given by the first element). The only great change I am suggesting is that it makes sense for this range to be an implicit part of any function whose first argument is in Ix. There is actually a more general issue here, which comes up if we regard the problem of defining bounds and array in the standard prelude, as is done now (without reference to a "prim" prefix). There can be many different representations of a function, or ways of defining a function (obviously). The present Haskell definition caters to this just fine, except for the fact that we cannot extend the definition of function application. The present MkArray definition is just fine, with the bounds of the function an explicit part of the data representation. However, I want to be able to treat these arrays as functions in every other sense: I want to evaluate them as functions, have functional composition defined, curry the function invocations, and so on. The problem with this is the notation of the new functions, and the relationship between those functions and other functions. Is the appropriate type signature for the array function as given above, or as in the standard prelude? What does this do for the ability to write functions that only apply to array functions, and not other functions? Is some type of extension to the constraint mechanism the best way to handle this? I am not sure how the parametric type class ideas tie into all this (if they do at all). I am also not as well read as I should be in the field of functional programming in general. Has anyone else suggested looking at arrays as functions? Has anyone thought of the general problem of alternative function representations? Sorry to be so elementary; it is one of the prices to pay for limited time to do the reading I should do as a matter of course. In any case, I think it is high time that we free ourselves of an imperative view of arrays and functions, and the differences between the two. Well, now I will see how many serious gaffes I have made...... Dave Barton [EMAIL PROTECTED]

- Re: Arrays and general function representation David Barton
- Re: Arrays and general function representation Rex Page
- Arrays and general function representation Martin Odersky
- Re: Arrays and general function representation Ken Sailor
- Re: Arrays and general function representation Ken Sailor
- Re: Arrays and general function representation Paul Otto
- Re: Arrays and general function representation Ken Sailor
- Re: Arrays and general function representation Rob Turner