On Friday 03 March 2006 10:52, Malcolm Wallace wrote: > Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> writes: > > > But if contexts-on-datatypes worked correctly, > > > data Set a = Ord a => .... > > > then even the "real" map from Data.Set: > > > map :: (Ord a, Ord b) => (a -> b) -> Set a -> Set b > > > could be an instance method of Functor. > > > > fmap ($0) . fmap const :: Functor f => f a -> f a > > > > When applied to Set Int, how would it represent the intermediate > > set of functions? Or if it was disallowed, on what basis? > > Clever example. The intermediate set is :: Set (Int->b->Int), which > does not satisfy the construction constraint (Ord a) => Set a. But > persuading the type system to reject this is tricky I agree. I'm not > a type hacker, so I don't know how to go about it. I suppose if the > complete set of class instances for the entire program were known, > then you could have a negation predicate, asserting that the > intermediate type (Int->b->Int) does not have an instance of Ord, and > somehow record this in the type environment > > fmap ($0) . fmap const :: (Functor f, not Ord a) => f a -> f a > > But then, there are a whole host of classes that (->) is not an > instance of, so this is pretty useless because the constraints will > grow enormously for little benefit. > > In short, I suppose the reason contexts-on-datatypes are as they are > currently, is because no-one yet knows how to solve your example.
Well, that is what wft constraints are for, see http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps where the above problem is discussed and a solution proposed. (hasn't this been discussed here, lately?) Ben _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
