AW: simulating dynamic dispatch
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. Interestingly, when I want hugs to show me the type of
fun::(forall a.[a]->Int)->[b]->[c]->Int it tells me: ERROR - Use of fun requires at least 1 argument Why that? At least I have explicitely specified the type.
Markus
One may want:
fun f x y = f x + f y
for instance:
fun length [True, False] [1,2]
Therefore, I would say, you need typing a la
fun::(forall a.[a]->Int)->[b]->[c]->Int
Ciao, Steffen
Interestingly, when I want hugs to show me the type of
fun::(forall a.[a]->Int)->[b]->[c]->Int it tells me: ERROR - Use of fun requires at least 1 argument Why that? At least I have explicitely specified the type.
Hmm, ghci behaves properly. But using hugs I get the same error :-(. No idea! Maybe some additional flags have to be set? Ciao, Steffen
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
participants (3)
-
Janis Voigtlaender -
Markus.Schnell＠infineon.com -
Steffen Mazanek