The Monomorphism Restriction

Tickets: #80, #131

The M-R is widely regarded as an ugly part of the Haskell 98 language definition. Here are the main alternatives on the table:

Remove it altogether

We could simply remove the M-R from the language, but suggest that compilers issue a warning when a loss of sharing might occur due to overloading of a variable or pattern binding.

For:

• Simple, removes a wart from the language
• "As much polymorphism as possible" is in the spirit of Haskell - it is strange to limit polymorphism for performance reasons (indeed, this is arguably a poor compromise)
• It turns out to be quite hard to demonstrate a performance problem due to the M-R, at least with GHC, because its optimiser often recovers the sharing.
• Even if you do get loss of sharing, profiling will quickly pinpoint it
• nhc98 has never implemented the M-R, and users haven't found any significant problems as a result
• Hugs has a different (non-Haskell98) implementation of the M-R
• Haskell doesn't specify an evaluation strategy so introducing the concept of 'sharing' is strange indeed.

Against:

• Might be hard to give an accurate warning; just warning about overloaded variable bindings isn't good enough, because they don't all result in loss of sharing.
• The warning might be confusing to new users (but if we could make it accurate, it wouldn't happen much)

A monomorphic binding operator

Introduce a new binding operator for monomorphic bindings, eg. :=.

See  John Hughes' proposal.

For:

• Simpler and more consistent than the M-R

Against:

• The reason for having two kinds of binding is subtle and hard to explain to newcomers.
• Still a wart, but an even more visible one.

A monomorphic binding syntax

behave just like the monomorhpic binding operator, but instead of having a new operator, use parens as in:

(shared) = 3 + 4    -- monomorphic binding

see  http://www.haskell.org//pipermail/haskell-prime/2006-January/000117.html

For:

• Simpler and more consistent than the M-R
• doesn't eat up a new operator
• can be seen as a degenerate case of the standard 'pattern matching is monomorphic' rule
• syntax makes it clear this is something that can happen to values and not functions
• we are already used to (=) being overloaded in this way

Against:

• would make parentheses matter in a certain situation (n+k patterns and negative literals already do this)

All variable/pattern bindings are monomorphic unless a signature is given

For:

• Simpler than the M-R
• Polymorphism in local variable bindings is rare (but less rare at the top-level), and can always be recovered with a type signature

Against:

• Against the spirit of Haskell - shouldn't compromise expressiveness for performance by default
• Already huge potential for ruining your performance without the M-R, why introduce such draconian measures just for this?
• Monomorphic bindings lead to hard to understand errors when polymorphism was expected
• Haskell doesn't define an operational semantics so introducing a concept of sharing into the report would be odd.