Joe (I am unable to discern a last name) writes:

>This may be painfully obvious, as well as syntactic and superficial,
>but since nobdoy's mentioned it up to now: If you want to treat an
>array a as a function, just use (a!) , e.g., f . (a!) . g

A similar comment occured recently.  It seems to me that my original
response applies: in some cases, you are interested in the specific
representation of an array or function, and in some cases you want to
ignore this.

The whole discussion interests me.  No one (for example) states that
addition should be defined on real numbers only, and integers can be
added together as Int (Real a + Real b), even though this is
technically correct.  The entire purpose behind the class facility
(and the more general parametric class facility mentioned by Martin
Odersky) is to allow us to overload functions and names such that
specific representations can be attended to or not, depending upon our
purposes and applications at the time.

>This, indeed, is the attitude toward arrays taken by the Haskell
>committee.  At the beginning of the Report section on arrays, we
>say that although in the abstract arrays should be regarded as
>functions, there are pragmatic reasons for treating them as data.

I continue to be interested in these.

>The opinion prevailing at the time we decided to distinguish array
>indexing syntactically from function application was that it would be
>difficult in general for a compiler to generate efficient code for an
>array access without the distinction.

Here I get very confused.  This seems not to be a problem for other
kinds of overloading.  The Wadler and Blott paper imply that this can
be taken care of by passing a dictionary of the appropriate functions
to a parametric function constrained by a context.  If all calls are
apropriately constrained, then beta reduction can make the array call
look just as it does not; if not (i.e., if functions or arrays are
passed), then the inefficiency is a product of the general nature of
the function definition.  How is this different from any other
application of type classes?

I thank Ken Sailor for his message without replying to it
specifically, as I think I understand and agree with his points.

                                        Dave Barton
                                        [EMAIL PROTECTED]

Reply via email to