Changes between Version 36 and Version 37 of Holes


Ignore:
Timestamp:
May 16, 2012 12:35:24 PM (3 years ago)
Author:
spl
Comment:

Respond to SLPJ on ambiguously typed holes

Legend:

Unmodified
Added
Removed
Modified
  • Holes

    v36 v37  
    240240We think holes can be extremely useful with ambiguous types. We prefer that a program, in which there is a hole with unsolved constraints on the type of the hole, still be considered well-typed, assuming the rest of the program is well-typed. In the above example, we would expect {{{show _?h}}} to have the type {{{String}}} with the reported hole type {{{_?h :: Show a => a}}}.
    241241
    242 '''SLPJ do you want programs with these ambiguity errors to run too?  Or what?  Can you give a complete little example module, with the error messages you expect, whether you expect it to run, and if so what should happen?'''
     242A hole with an ambiguous type should be treated as a hole runtime error (and not a deferred type error with {{{-fdefer-type-errors}}}). See [#Runtimeerror Runtime error] for an example.
    243243
    244244==== Monomorphism restriction ====
     
    265265Given the following module:
    266266{{{
    267 main = _?x
     267main = _?x >>= return
    268268}}}
    269269we expect (something like) the runtime error:
    270270{{{
    271 blah: blah.hs:2:1:
     271blah: blah.hs:2:8:
    272272    Found the hole `_?x' with type `IO t'
    273     In the expression: _?x
    274     In the definition of `main': main = _?x
    275 }}}
     273    In the expression: _?x >>= return
     274    In the definition of `main': main = _?x >>= return
     275}}}