Re: [Haskell-cafe] Polymorphic algebraic type constructors

to be [] in each case.
ahh but in this example: f :: [Int] -> [Bool] f (i:is) = even i : f is f e@[] = e e is an empty list of Ints not an empty list of Bools! you mean: f :: [Int] -> [Bool] f (i:is) = even i : f is f _ = [] Keean.

On Tuesday 22 Jun 2004 6:20 pm, MR K P SCHUPKE wrote:
ahh but in this example:
f :: [Int] -> [Bool] f (i:is) = even i : f is f e@[] = e
e is an empty list of Ints not an empty list of Bools!
If the difference is significant (I don't believe it is) then consistency demands that this expression should give a type error.. let e=[] in (length e : e, null e : e) It doesn't, so clearly e can be both an empty list of Ints and an empty list of Bools :-) Regards -- Adrian Hey

On Tue, 2004-06-22 at 20:52, Adrian Hey wrote:
On Tuesday 22 Jun 2004 6:20 pm, MR K P SCHUPKE wrote:
ahh but in this example:
f :: [Int] -> [Bool] f (i:is) = even i : f is f e@[] = e
e is an empty list of Ints not an empty list of Bools!
If the difference is significant (I don't believe it is) then consistency demands that this expression should give a type error..
let e=[] in (length e : e, null e : e)
It doesn't, so clearly e can be both an empty list of Ints and an empty list of Bools :-)
I think the point is that [] (or e in your example) has type forall a.[a] where as in the original example e was bound to an argument with the type [Int], so e could not be used where something of type [Bool] was required. On the other hand [] :: forall a.[a] could be used in either context. Duncan

On Tuesday 22 Jun 2004 9:09 pm, Duncan Coutts wrote:
I think the point is that [] (or e in your example) has type forall a.[a] where as in the original example e was bound to an argument with the type [Int], so e could not be used where something of type [Bool] was required. On the other hand [] :: forall a.[a] could be used in either context.
Whilst I understand perfectly well why this inconsistency arises, I don't agree that this is the point :-) I think the point is this inconsistency should not arise. I think that function definitions of form.. f v@<pat> = <expr> should be type checked as if they had been written.. f <pat> = let v = <pat> -- assuming <pat> is syntactically correct expr in <expr> Same applies to case expressions to. Of course one would need to be careful if <pat> contained '_'. However, cases like this.. f (i:is) = even i : f is f e = e are a bit more ambiguous. Although we all know e must be [], that isn't immediately obvious. So I guess the answer depends on whether type checking should be done before or after pattern match compilation. Regards -- Adrian Hey
participants (3)
-
Adrian Hey
-
Duncan Coutts
-
MR K P SCHUPKE