Export lists in modules

[Malcolm Wallace]

Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> 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.

Regards,
    Malcolm