Changes between Version 22 and Version 23 of Holes


Ignore:
Timestamp:
May 3, 2012 10:24:02 AM (3 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 ===