Changes between Version 6 and Version 7 of MonomorphismRestriction


Ignore:
Timestamp:
May 14, 2008 3:08:41 PM (6 years ago)
Author:
simonmar@…
Comment:

move the proposals into separate pages

Legend:

Unmodified
Added
Removed
Modified
  • MonomorphismRestriction

    v6 v7  
    55The M-R is widely regarded as an ugly part of the Haskell 98 language definition.  Here are the main alternatives on the table: 
    66 
    7 == Remove it altogether == 
     7 * [wiki:MonomorphismRestriction/Remove] 
     8 * [wiki:MonomorphismRestriction/MonomorphicBindingOperator] 
     9 * [wiki:MonomorphismRestriction/MonomorphicBindingSyntax] 
     10 * [wiki:MonomorphismRestriction/Optional] 
     11 * [wiki:MonomorphismRestriction/MonomorphicVariableAndPatternBindings] 
     12  
    813 
    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