AW: simulating dynamic dispatch

[Janis Voigtlaender]

Markus.Schnell@infineon.com wrote:
> 
> I think I get it. But to be sure:
> The forall means: The type for a may not be the same
> throughout the whole function. It just has to follow
> the pattern specified inside the braces.

Not exactly. In:

> > fun::(forall a.[a]->Int)->[b]->[c]->Int
> > fun f x y = f x + f y

the forall means that the first argument to fun must be polymorphic, as
in:

> > fun length [True, False] [1,2]

It is not enough "to follow the pattern". If, e.g., you have a function
sum::[Int]->Int (which does "follow the pattern", if I understand
correctly what you mean with this), you may NOT say something like:

    fun sum [1,2] [3,4]

however sensible this might seem at first look.

The reason is that sum only works on integer lists, whereas the given
type for fun requires that the first argument be a function that works
on lists of any type, such as length.
If sum were allowed as argument to fun, then we would also have to be
allowed to say:

    fun sum [True, False] [1,2]

which clearly makes no sense.

That Hugs refuses to report the type of fun has to with the fact that
such (rank-2) types cannot be inferred. GHC generally has better support
for higher-ranked types (no general inference, of course).

Hope that helped,
Janis.

--
Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:voigt@tcs.inf.tu-dresden.de