Reginald Meeson writes:
>Interesting discussion, but it seems to me that Haskell already
>provides the best of both worlds, namely
>
> a. Efficient implementation of arrays as data objects, with indexing
> as a projection function; and
>
> b. Definition of functions with (Ix a) domains by indexing an array
> behind the scenes or by any other rule.
>
>Arrays satisfy the needs of an important user community. Is there
>something more needed to satisfy the general-function community?
For the same reason that the features of parametric functions and type
classes in general are useful: in some cases, you want to treat the
object like an array (for instance, building and updating), and in
some cases you want to treat the object like a function (accessing,
currying, functional composition).
At least part of my argument is a theoretical one: arrays are
functions, and should look like them. A much larger part is
practical: I am working in an environment where there are a lot of
different function representations, of which Haskell-type functions,
arrays, dual arrays (domain and range) with an interpolation function,
and specific triples which assume an underlying sine function are only
a few. These functions need to be specified in accordance with their
representations; however, outside the original specification, they are
used as functions (with an entire class structure, similar to the type
strucuture in the standard prelude. of functions that are applicable
on them). To specify both the object and a separate function that
incorporates the object is at least extremely inconvenient.
Dave Barton
[EMAIL PROTECTED]
