| 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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
