| Instead, let me propose a slight change of shade: put the "required" | constraints *first* and the "provided" ones *second*. Of course, we could | leave out the required constraints. I'm agnostic about this choice at the moment, but I don't understand your points. | So, continuing the examples from earlier, we have | | > pattern P :: forall a. Num a => forall c. (Eq a, Ord Bool, Show c) => c | -> Bool -> T a Bool | > pattern C :: (Eq b, Num b) => () => b -> c -> X Maybe (Maybe b) In these examples, can you just remind us of which are match-required and which are match-provided? | - If you write the `forall`s in, the scope builds left to right. In the | other order, the scoping is very bizarre. Can you be more explicit? I don't understand. | - I think of the "provided" bits + arguments of the constraint as what is | matched against. The order I propose keeps these pieces together. Can you give a concrete example? I don't understand. | Whatever syntax we choose, I would highly recommend putting in a helpful | link to more information in error messages. In principle I like this very much, but I have always stumbled on - writing links that will remain stable for ever (and are hence release-specific) - keeping them up to date when the version changes - making them easy to test e.g. in my build tree Separate question really, but would need some systematic attention to make it work properly in general. Simon