The monomorphism restriction and monomorphic pattern bindings

[Simon Peyton-Jones]

| Iavor:
| the change is valid.  I do believe that you can probably work around
| the problem in many situations but the question in my mind is "why
| should we have to work around stuff when we have a system that already
| works?"  In other words, what problem do MBPs solve?
...
| Neil:
| Haskell has always had the attitude of doing what suits users, and
| making implementations work hard to handle the language features. In
| addition, this is a breaking change.


I have not made my case well!

1.  [Minor point] In general I agree with what Iavor and Neil say above, but it should not be an Iron Law.  If a small and easily-describable restriction in programming yields a significant simplification in implementation, that's a benefit that may be worth having.

2. More importantly, I am using System F *not* because it tells us about GHC's implementation, but because I have found that it's an excellent "litmus test" that tells when something smelly is going on.  The fact that one has to go through contortions to translate pattern bindings is a Bad Sign, I believe.

3. I'm more concerned about the programmer than the implementation.  Consider
        (f,g) = (negate, show)
What type do you expect 'f' to have?  A straightforward answer might be
        f :: (Num a, Show b) => a -> a
If you don't want that, you need to explain a more complicated typing rule for pattern bindings.    I'll ask the same about
        (f,g) = (reverse, length)
A simple and consistent story is that all the pattern bound variables are generalised over all the class constraints and all the type variables of the RHS.  But I bet that is not what you want.

4.  Would it make a difference if you gave a type signature for f?  Can f,g have different sets of class constraints?  (H98 says 'no' for class constraints, but 'yes' for type variables, which is an obvious wart).

5.  I'm also concerned about the interaction with strictness.
        let (f,g) = e in f (...f...g...)
Here 'f' is clearly used strictly, so the pair will certainly be evaluated.  Does this mean the same?
        case e of (f,g) -> f (...f..g...)

6.  If we allow bang patterns, what does
        !(f,g) = e
actually mean?


The implementation is not the driving force.  It's just the way I know that something is afoot.

What is the problem MPB tries to solve?  The problem of specifying the type system for pattern bindings. Try writing down the full typing rules for pattern bindings, including type signatures!  Higher-rank types too.

Simon