The monomorphism restriction and monomorphic pattern bindings

[Neil Mitchell]

Hi Simon,

Those additional reasons given are much more compelling, and should
definately go on the wiki. I think the essential point is that it
makes reasoning about the code simpler - regardless of the effect on
implementation.

My main remaining reservation is that:

(x) /= x
x at x /= x

It really worries me that

(caf) = foo

Can be in an entirely different complexity class from caf = foo. It
seems like the kind of "refactoring" that beginners will be
immediately drawn to, and even experienced programmers will get
tripped up on. Anyone doing (caf) is virtually going to be required to
add a comment just above stating that the brackets are essential.

Does it still work if you relax the definitions so that x at y is a
pattern binding only if y is a pattern binding, and (x) is a pattern
binding only if x is a pattern binding?

Thanks

Neil


On 4/25/08, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
> | The report doesn't actually mention this translation although it is
>  | widely used to implement pattern bindings, and in some compilers (not
>  | GHC) the translation is done before type checking.
>  |
>  | What's interesting to me is that perhaps this gives us a way to
>  | understand what the static semantics of pattern bindings should be,
>  | absent MPB. e.g.
>
>
> Yes, that's a fine point.  If this became the formal definition of the *static* semantics of pattern bindings, that would be a significant improvement, because it'd give us a precise way to answer the various questions I asked. (We might or might not like the answers, but at least we could answer them.)
>
>
>  Simon
>  _______________________________________________
>  Haskell-prime mailing list
>  Haskell-prime at haskell.org
>  http://www.haskell.org/mailman/listinfo/haskell-prime
>