Tim Sweeney wrote:
> However, a higher-order notion of function application seems sensible in
> many cases. For example, consider the following expressions, which Haskell
> rejects, despite an "obvious" programmer intent:
Casting was done quite extensively by Algol68 (though not of this form).
A classic example: in the assignment
x := y + 2
suppose that the values x and y are declared to be references to integer. 2 is of
course
an integer. Then y is implicitly dereferenced to get a pure integer. Dereferencing
can occur any number of times. Compare this with ML (using refs) or Haskell (using
IORefs)
where you'd have to put a dereference to y in explicitly.
Other coercions were: you could use a value as if it were an array containing
that value; you could use a function of type (Haskell notation)
() -> A as if it were a value of type A (the function would implicitly be called)
and so on.
The rules for exactly what coercions can and can't be used exactly where in
Algol68 are extremely complicated. (There are different contexts in which
different casts are permitted.) However I used Algol68 to write quite a bit
of code about 10 years ago and I usually found that it worked as I intuitively
expected, even though I didn't understand the rules.
However in my own opinion I think that Haskell's type system and error messages
are already complicated enough; indeed probably too complicated. I would not
favour extending Haskell to allow such friendly coercions.
