Subject: |
Re: [Haskell-cafe] Language extensions [was: Memoization] |
---|---|

From: |
Andrew Coppin |

Date: |
Tue, 29 May 2007 21:28:07 +0100 |

Claus Reinke wrote:
Hahahaha! Thanks for a good laugh! I should print this out and *frame* it or
something...
in exchange, below is a quick summary (didn't we have a Mmm... Still not seeing a great amount of use for this one. quantified types (forall/exist): an easy way to memorize this is to think of 'forall' as a big 'and' and of 'exists' as a big 'or'. e :: forall a. a -- e has type 'Int' and type 'Bool' and type .. e :: exists a. a -- e has type 'Int' or type 'Bool' or type .. That doesn't entirely make sense. (What am I on about? That doesn't make
*any* sense...)
rank-N polymorphism: in rank-1 polymorphism, type variables can only stand for monomorphic types (so, '($) :: (a->b) -> a -> b' can only apply monomorphic functions to their arguments, and polymorphic functions are not first-class citizens, as they cannot be passed as parameters without their types being instantiated). in rank-N (N>1) polymorphism, type-variables can stand for rank-(N-1) polymorphic types (in other words, polymorphic functions can now be passed as parameters, and used polymorphically in the body of another function). f :: (forall a. [a]->Int) -> ([c],[d]) -> (Int,Int) f g (c,d) = (g c,g d) f length ([1..4],[True,False]) It's actually news to me that you can't do this already... (!) functional dependencies: when using multi-parameter type classes, we specify relations between types (taken from the cartesian product of type class parameters). without additional measures, that tends to lead to ambiguities (some of the type class parameters can not be deduced unambiguously from the context, so no specific type class instance can be selected). functional dependencies are one such measure to reduce ambiguities, allowing us to specify that some subset A of type-class parameters functionally determines another subset B (so if we know the types of the parameters in subset A, there is only a single choice for the types of the parameters in subset B). Functional dependancies kind of make sense. Personally I like the idea
of associated types better, but never mind.
gadts: what really makes them different is that the explicit type signatures for the data constructors can give more specific return types for the data constructs, and such more specific types can be propagated through pattern matching Finally, a definition of GADTs that actually makes some kind of sense... (I find it highly unlikely I'll ever need these, but at least I have
some idea now what they're supposed to do.)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@xxxxxxxxxxx http://www.haskell.org/mailman/listinfo/haskell-cafe |

Previous by Date: | Re: [Haskell-cafe] New book: Real-World Haskell!, Doug Kirk |
---|---|

Next by Date: | Re: [Haskell-cafe] Mysterious monads, Andrew Coppin |

Previous by Thread: | Re: [Haskell-cafe] Language extensions [was: Memoization], Claus Reinke |

Next by Thread: | Re: [Haskell-cafe] Language extensions [was: Memoization], Ketil Malde |

Indexes: | [Date]
[Thread]
[Top]
[All Lists] |