Changes between Version 22 and Version 23 of Holes


Ignore:
Timestamp:
May 3, 2012 10:24:02 AM (2 years ago)
Author:
xnyhps
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Holes

    v22 v23  
    201201=== Ambiguous types === 
    202202 
    203 If type-checking would fail due to unsolved constraints that could be solved by giving a type to a hole, then the program should still be considered well-typed. This mainly occurs when types are ambiguous, with class constraints and no concrete types. If you replace the hole in the expression {{{show _?h}}} with {{{undefined}}}, then {{{show undefined}}} has an unsolved {{{Show}}} constraint and is ill-typed. But with the hole, we would prefer {{{show _?h}}} to be well-typed with a reported hole type {{{_?h :: Show a => a}}}. 
     203If type-checking would fail due to unsolved constraints that could be solved by giving a concrete type to a hole, and if by ignoring these ambiguous constraints the program would be well-typed, then the program itself should be considered well-typed. This mainly occurs with class constraints and no concrete types on the hole that do not show up in the type signature of the function itself. If you replace the hole in the expression {{{show _?h}}} with {{{undefined}}}, then {{{show undefined}}} has an unsolved {{{Show}}} constraint and is ill-typed. But with the hole, we would prefer {{{show _?h}}} to be well-typed with a reported hole type {{{_?h :: Show a => a}}}. 
    204204 
    205205=== Monomorphism restriction === 
    206206 
    207 The above expectations should hold with and without the monomorphism restriction. In particular, if an {{{undefined}}} somewhere in a program type-checked with the monomorphism restriction would cause type-checking to fail, then a hole in that same position should also cause type-checking to fail. 
    208  
    209 '''NOTE''': Give example. 
     207There is a special case of ambiguous types caused by the monomorphism restriction. For example, without `-XNoMonomorphismRestriction`, the following function, specified without a type signature will fail: 
     208{{{ 
     209f = _?h >>= _?i 
     210}}} 
     211 
     212with the following error: 
     213 
     214{{{ 
     215Warning: 
     216    No instance for (Monad m0) arising from a use of `>>=' 
     217    The type variable `m0' is ambiguous 
     218    Possible cause: the monomorphism restriction applied to the following: 
     219      f :: m0 b0 
     220    Probable fix: give these definition(s) an explicit type signature 
     221                  or use -XNoMonomorphismRestriction 
     222    In the expression: _?h >>= _?i 
     223    In an equation for `f': f = _?h >>= _?i 
     224}}} 
     225 
     226In this case, the class constraint is ambiguous, however, if that would be ignored, it would still be impossible to specify a type for `f` as that would violate the monomorphism restriction. 
    210227 
    211228=== Type of a hole ===