[GHC] #5624: Delay Errors Until Runtime

GHC cvs-ghc at haskell.org
Fri Nov 11 20:41:08 CET 2011


#5624: Delay Errors Until Runtime
---------------------------------+------------------------------------------
    Reporter:  atnnn             |        Owner:  atnnn       
        Type:  feature request   |       Status:  new         
    Priority:  high              |    Milestone:  7.6.1       
   Component:  Compiler          |      Version:  7.3         
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by atnnn):

 Thanks for the feedback. Your analysis of my proof of concept is correct.

 > * I don't really grok the types of findIn etc

   findIn :: (a -> b) -> a -> SrcSpan -> Maybe (HsExpr RdrName, HsExpr
 RdrName -> b)

 findIn is a zipper traversal of a subtree a in a root tree b. It returns
 when it finds an HsExpr with the given SrcSpan.

 Most instances implement a more general findIn :: (a -> b) -> a -> Reader
 c d

 > * What if the SrcSpan doesn't match exactly?

 The error is left as-is and typechecking isn't retried.

 > * What happens if you have an error in a type signature, or a type
 declaration; then there is no obvious expression to replace.

 Nothing currently happens, but the type of findIn can be generalised to
 find something else that HsExprs.

 > But I'd like to tell you about my cunning plan.

 > it generates an equality constraint that looks like g :: ty2 ~ ty1

 How is this different than using x itself as evidence that ty2 ~ ty1 and
 replacing x with bottom if not?

 > Moreover, the post-typechecked expression looks like (f (x |> g))

 This seems to lead to a blowup (((f |> f'ev) (x |> x'ev)) |> f_x'ev),
 would it have an effect on performace? (If *'ev = id, it might even lead
 to #5621 :P)

 > IMHO this is rather elegant: precisely when the runtime execution needs
 evidence that ty1 = ty2, and no sooner, you'll get the error.

 That's what I want.

 > Like, if f happens not to use its argument, you can run (f x) without
 getting the error.

 This is the current behaviour.

 I agree, my approach is a hack. It started as a bash/perl script that
 parsed the output of ghc.

 > If you are interested, I can help point you at the right places.

 I would love to discuss more about this and other ideas better than mine
 and implement or adapt one of them.

 Etienne Laurin

 a Haskell programmer from Montreal

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5624#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler



More information about the Glasgow-haskell-bugs mailing list