Thanks! These examples and counterexamples help a lot
in understanding.
Markus
> 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 argumen
[EMAIL PROTECTED] 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
> 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 :-(.
N
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 -
> concrete: What is the difference between
> (forall b. Term b => b -> b) -> a -> a
> and
> (Term b) => (b -> b) -> a -> a
> ?
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]->
> http://research.microsoft.com/~simonpj/papers/hmap/
The technique you describe in that paper is exactly what I was
wanting for many times. I often stopped using algebraic data types
because of the immense amount of boilerplate I had to introduce.
Thanks!
But now I have a question regarding th
