Re: [Haskell-cafe] Polymorphic algebraic type constructors

Adrian Hey wrote: I think all occurences of [] have type forall a. [a] The case expression.. case a of (a':as) -> <expr1> [] -> <expr2> Should be typed as if written.. case a of (a':as) -> let a=(a':as) in <expr1> [] -> let a=[] in <expr2> ---------------------------------------------------- Well, we will have to agree to disagree, I find the current system makes perfect sense, and is easy to reason with. If I want a let binding I can write one. The difference is really this: case a of (a:as) -> <expr1> e -> e In this case e represent 'the same []' as on the left hand side. in the let binding this is a new and fresh '[]'... When I pattern match a variable in a case extression I really expect it to get the type of the case... There are circunstances when I go on to use e, and if it is not grounded by the case expression I will get hit by the monomorphoism restriction, and have to add non haskell98 type annotation to ground 'e'... for example If I pass e to a polymorphic function, it won't know what type e has... case a of (a':as) -> let a=(a':as) in <expr1> [] -> let a=[] in (polyfn a) where polyfn a has a type like polyfna :: Ord a -> [a] -> String Now the above won't work and you will have to do: [] -> let a=[] in (polyfn (a :: [SomeListType])) and of course if you are using generics then how can polyfn get the original type of 'a' in the case expression... for example: polyfn :: Typable a -> [a] -> ShowS polyfn a = shows (typeOf a) then: case a of (a:as) -> <expr1> e -> polyfn e is correct, but: case a of (a':as) -> let a=(a':as) in <expr1> [] -> let a=[] in (polyfn a) does what? Keean.

On Wednesday 23 Jun 2004 2:08 pm, MR K P SCHUPKE wrote:
If I want a let binding I can write one.
The trouble with this is that a sub-optimal (I don't like to use the word "naive") implementation will actually create a new heap construction, rather than re-use the one it knows (or should know) it already has (as a result of pattern matching). This probably isn't a problem with zero arity constructors like [] which AFAIK are universally shared anyway in GHC (and probably other Haskell implementations). Example, if instead of.. f v@(Left s) = <expr> a programmer has to write.. f (Left s) = let v=Left s in <expr> Of course there's no reason in principle why a reasonably smart compiler should optimise out the unnecessary construction AFAICS, and I think last time this was discussed there was talk of doing this with ghc. Dunno if it does though, or about other Haskell implementations. The programmer could help out the less smart compilers a bit by using "as patterns", if it wasn't for the fact that this often results in a type error. Regards -- Adrian Hey
participants (2)
-
Adrian Hey
-
MR K P SCHUPKE