> I share Greg's concerns about polymorphic projections. For example, > given a function > > sort :: Ord a => ... > > we don't allow any 'a' that happens to export a operator that's > spelled <= to be passed to 'sort'. We have the user explicitly create > an instance and thereby defining that their <= is e.g. a strict weak > ordering and thus make sense when used with 'sort'. This explicitness > is useful, it communicates the contract of the function to the reader > and lets us catch mistakes in a way that automatically polymorphic > projections don't.
But the difference is that <= is (potentially) an arbitrary function, so we need to be careful that the instances make sense. A formally correct system would insist that all instances are (at least) reflexive and transitive. But in the case of records, we know what the instances are: they are projection functions. Every single (automatically generated) instance does exactly the same thing: it projects out one component of a record. This isn't like OO polymorphism, where "messages" are actually arbitrary functions which could do anything, the polymorphism is exactly the same as that of fst and snd. > At the very least use two different LANGUAGE pragmas so users can have > one without the other. This I can agree with. It was the way that Greg mentioned it in every single email which was starting to worry me. Barney. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
