David Barton writes: 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. and then goes on: I am not sure how the parametric type class ideas tie into all this (if they do at all). Well, parametric type classes can give you a type-systematic basis for doing this. Using some of the notation of our Lisp and FP '92 paper, you could define: class f :: Function a b where -- the class of functions ($) :: f -> a -> b -- 'apply' is expressed as infix '$'. inst a -> b :: Function a b where -- '->' is the classical instance type f $ x = f x class (f :: Function a b, a :: Ix) => f :: FiniteFunction a b where dom: f -> (a, a) -- the class of finite functions -- (with rectangular domains), -- defined as a subclass of Function inst Array a b :: FiniteFunction a b where arr $ x = arr ! x -- an instance of a finite function dom arr = bounds arr You might object that all we did was exchange one awkward symbol for indexing (!) by another ($). To be able to use juxtaposition for array indexing, we need to get a "handle" on juxtaposition. One way to do that would be by decreeing: f x is syntactic sugar for f$x . In that case we need to adapt the instance declaration of arrow: inst a -> b :: Function a b where f $ x = primApply f x And we are done. However, I am not sure we want to do that, since principal types become very unwieldy. For instance, if composition were defined as usual (f . g) x = f (g x) , its principal type would be (ft :: Function b c, gt :: Function a b) => ft -> gt -> a -> c. [Aside: This is another example where multiple argument type classes lead to ambiguities, but parametric type classes don't.] The principal type is what it should be, since each of f and g can be an array instead of a function (or it can be some other instance of class Function). You see, the cost of generality is increased complexity of many principal type expressions. I am not sure whether this cost is worth the gains (it might be). On the other hand, having an explicit overloaded infix operator for application does not seem to complicate anything. -- Martin Odersky

- Arrays and general function representation David Barton
- Re: Arrays and general function representation Rex Page
- Re: 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