[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