Concrete syntax for pattern synonym type signatures

Simon Peyton Jones simonpj at
Mon Nov 10 21:07:58 UTC 2014

| 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.


More information about the ghc-devs mailing list