| 9 | | 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. |
| 10 | | |
| 11 | | 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. |
| 12 | | |
| 13 | | '''For:''' |
| 14 | | * Simple, removes a wart from the language |
| 15 | | * "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) |
| 16 | | * 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. |
| 17 | | * Even if you do get loss of sharing, profiling will quickly pinpoint it |
| 18 | | * nhc98 has never implemented the M-R, and users haven't found any significant problems as a result |
| 19 | | * Hugs has a different (non-Haskell98) implementation of the M-R |
| 20 | | * Haskell doesn't specify an evaluation strategy so introducing the concept of 'sharing' is strange indeed. |
| 21 | | |
| 22 | | '''Against:''' |
| 23 | | * 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. |
| 24 | | * The warning might be confusing to new users (but if we could make it accurate, it wouldn't happen much) |
| 25 | | * 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. |
| 26 | | |
| 27 | | == A monomorphic binding operator == |
| 28 | | |
| 29 | | Introduce a new binding operator for monomorphic bindings, eg. {{{:=}}}. |
| 30 | | |
| 31 | | See [http://www.haskell.org//pipermail/haskell-prime/2006-January/000038.html John Hughes' proposal]. |
| 32 | | |
| 33 | | '''For:''' |
| 34 | | * Simpler and more consistent than the M-R |
| 35 | | |
| 36 | | '''Against:''' |
| 37 | | * The reason for having two kinds of binding is subtle and hard to explain to newcomers. |
| 38 | | * Still a wart, but an even more visible one. |
| 39 | | |
| 40 | | == A monomorphic binding syntax == |
| 41 | | |
| 42 | | behave just like the monomorhpic binding operator, but instead of having a new |
| 43 | | operator, use parens as in: |
| 44 | | |
| 45 | | {{{ |
| 46 | | (shared) = 3 + 4 -- monomorphic binding |
| 47 | | }}} |
| 48 | | |
| 49 | | see http://www.haskell.org//pipermail/haskell-prime/2006-January/000117.html |
| 50 | | |
| 51 | | '''For:''' |
| 52 | | * Simpler and more consistent than the M-R |
| 53 | | * doesn't eat up a new operator |
| 54 | | * can be seen as a degenerate case of the standard 'pattern matching is monomorphic' rule |
| 55 | | * syntax makes it clear this is something that can happen to values and not functions |
| 56 | | * we are already used to (=) being overloaded in this way |
| 57 | | |
| 58 | | '''Against:''' |
| 59 | | * would make parentheses matter in a certain situation (n+k patterns and negative literals already do this) |
| 60 | | |
| 61 | | == ability to choose on a module by module basis == |
| 62 | | |
| 63 | | Just like we have a directive for controlling the defaulting behavior in the |
| 64 | | type checker, we can have a directive for turning on/off the monomorphism |
| 65 | | restriction when infering types for a given module. |
| 66 | | |
| 67 | | == All variable/pattern bindings are monomorphic unless a signature is given == |
| 68 | | |
| 69 | | '''For:''' |
| 70 | | * Simpler than the M-R |
| 71 | | * Polymorphism in local variable bindings is rare (but less rare at the top-level), and can always be recovered with a type signature |
| 72 | | |
| 73 | | '''Against:''' |
| 74 | | * Against the spirit of Haskell - shouldn't compromise expressiveness for performance by default |
| 75 | | * Already huge potential for ruining your performance without the M-R, why introduce such draconian measures just for this? |
| 76 | | * Monomorphic bindings lead to hard to understand errors when polymorphism was expected |
| 77 | | * Haskell doesn't define an operational semantics so introducing a concept of sharing into the report would be odd. |
| 78 | | |
