... | ... | @@ -5,89 +5,8 @@ |
|
|
|
|
|
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 implementations issue a warning when a loss of sharing might occur due to overloading of a variable or pattern binding.
|
|
|
|
|
|
|
|
|
The warning would not be mandatory - the report doesn't mandate implementation behaviour of this kind, rather it would be a recommendation. To make the warning mandatory would require talking about operational semantics, which the report also doesn't do.
|
|
|
|
|
|
**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)
|
|
|
- For cases where you want the polymorphic type and don't want to write a type signature, then having the compiler emit a warning by default is undesirable.
|
|
|
|
|
|
## A monomorphic binding operator
|
|
|
|
|
|
|
|
|
Introduce a new binding operator for monomorphic bindings, eg. `:=`.
|
|
|
|
|
|
|
|
|
See [ John Hughes' proposal](http://www.haskell.org//pipermail/haskell-prime/2006-January/000038.html).
|
|
|
|
|
|
**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:
|
|
|
|
|
|
```wiki
|
|
|
(shared) = 3 + 4 -- monomorphic binding
|
|
|
```
|
|
|
|
|
|
|
|
|
see [ http://www.haskell.org//pipermail/haskell-prime/2006-January/000117.html](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)
|
|
|
|
|
|
## ability to choose on a module by module basis
|
|
|
|
|
|
|
|
|
Just like we have a directive for controlling the defaulting behavior in the
|
|
|
type checker, we can have a directive for turning on/off the monomorphism
|
|
|
restriction when infering types for a given module.
|
|
|
|
|
|
## 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. |
|
|
- [MonomorphismRestriction/Remove](monomorphism-restriction/remove)
|
|
|
- [MonomorphismRestriction/MonomorphicBindingOperator](monomorphism-restriction/monomorphic-binding-operator)
|
|
|
- [MonomorphismRestriction/MonomorphicBindingSyntax](monomorphism-restriction/monomorphic-binding-syntax)
|
|
|
- [MonomorphismRestriction/Optional](monomorphism-restriction/optional)
|
|
|
- [MonomorphismRestriction/MonomorphicVariableAndPatternBindings](monomorphism-restriction/monomorphic-variable-and-pattern-bindings) |
|
|
\ No newline at end of file |