Changes between Version 38 and Version 39 of Holes

May 17, 2012 8:00:52 AM (4 years ago)



  • Holes

    v38 v39  
    141141Note that all type variables should be the same for all reports, so all types above refer to the same `m`.
     143'''SLPJ''' see comments below about class constraints on the holes. '''End of SLPJ'''
    143146=== Expressions ===
    159162Inferred type: MonadPlus m => m b
    161 Again, note that the type variables are universally quantified over all reports, not each report separately.
     164Again, note that the type variables are universally quantified over all reports, not each report separately.  '''SLPJ''' I have no idea what this sentence means.  '''End of SLPJ'''.
     166'''SLPJ'''.  I am very uncomfortable with saying anything like
     168Inferred type: MonadPlus m => m b
     170for two reasons:
     171 * First, that absolutely is not the inferred type of the hold.  Imagine that I added a binding
     173boo :: MonadPlus m => m b
     175 and replaced the last line of the example with
     177  y `mplus` boo
     179 Would it type check?  Absolutely not!  Adding type constraints on the types of the holes seems wierd and and impossible to justify.
     181 * Second, the need for `MonadPlus` is nothing to do with the holes. It's to do with the call to `mplus` and the do-notation. It seems wrong to implicate the hole.
     182'''End of SLPJ'''
    163185=== Comparison ===
    253275If we instead allow the program to type-check, we can find out what type the hole should have ({{{_?h :: Show a => a}}} in this case) and more information.
     277'''SLPJ''' I would rather put it like this. If I wrote
     279f :: String
     280f = show undefined
     282then I '''want''' an ambiguity error.  And that is supposed to be what holes are equivalent to (see above).  But, you may argue, there is no point in reporting a cascade of errors that follow from the absence of information about a hole.  It's just distracting.  So here's an idea:
     283 * With `-XHoles` we autmatically behave like `-fdefer-type-errors` for any unsolved type constraint that shares a free unification variable with a hole.
     284The idea is that if we have a hole of type `a`, then an unsolved `(Show a)` or `(C [a])` or `F a ~ Int` or anything mentioning `a` are automatically deferred and perhaps not even reported as warnings (unsure on this point). If you run the program you might trip over one of them, of course.
     285'''End of SLPJ'''
    255287A hole with an ambiguous type should probably be treated as a hole runtime error and not a deferred type error (see [#Runtimeerror Runtime error] for an example); however, not all holes are the immediate cause of ambiguity type errors. For example, consider: