# Arrays and general function representation

```
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

```