Yes that looks plausible, though I assume you meant | class ( | Monad m, | forall a. Monoid (m a) | ) => MonadPlus m I.e. parens round the (m a). This business of having 'foralls' in a context (whether for a class or a function) is not hard to implement in principle, but in practice it'd take few days of hacking I guess. And, more to the point, thinking. What are the interactions with functional dependencies or implicit parameters? (Maybe none, but I've been caught before.) So it's really waiting for someone to say "having foralls in contexts would change my life and I would love you for ever", rather than "it'd be nice". Simon "lazy evaluation" PJ | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 19 July 2002 03:24 | To: Simon Peyton-Jones; Haskell List | Subject: RE: foralls in class assertions | | | At 2002-02-20 13:15, Simon Peyton-Jones wrote: | | >OK, so it does look as though it's the same idea as | >that described in our paper. Good. | > | >I have not implemented, yet. | | I don't suppose you did for GHC 5.04?... | | >As always my implementation | >priorities are strongly influenced by my perception of whether some | >enhancement would be used. Maybe you can outline why such a change | >would be useful to you? I only have the example in our paper as | >motivation so far. | | I just thought of another motivating example for this: | | class Monoid a where | mempty :: a | mappend :: a -> a -> a | mconcat :: [a] -> a | | class ( | Monad m, | forall a. Monoid m a | ) => MonadPlus m | | Of course, you folks might not want to rewrite | Control.Monad.MonadPlus. | But I think is shows this sort of thing is useful in | principle (and it | would great for my HBase, which does its own Prelude). | | -- | Ashley Yakeley, Seattle WA | |