#10569: Treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fb7b6922573af76a954d939c85e6af7c39a19896/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fb7b6922573af76a954d939c85e6af7c39a19896" Treat out-of-scope variables as holes This patch implements the idea in Trac #10569. * An out-of-scope variable is treated as a typed expression hole. * That is, we don't report it in the type checker, not the renamer, and we when we do report it, we give its type. * Moreover, we can defer the error to runtime with -fdefer-typed-holes In implementation terms: * The renamer turns an unbound variable into a HsUnboundVar * The type checker emits a Hole constraint for a HsUnboundVar, and turns it back into a HsVar It was a bit painful to implement because a whole raft of error messages change slightly. But there was absolutely nothing hard in principle. Holes are reported with a bunch of possibly-useful context, notably the "relevant bindings". I found that this was distracting clutter in the very common case of a mis-typed variable that is only accidentally not in scope, so I've arranged to print the context information only for true holes, that is ones starting with an underscore. Unbound data constructors use in patterns, like f (D x) = x are still reportd by the renamer, and abort compilation before type checking. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10569#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10569: Optionally treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ertes): * status: closed => new * version: 7.10.1 => 8.0.1 * resolution: fixed => Comment: Can we please make this behaviour optional, and ideally off by default? In an interactive rapid-prototyping workflow this is a major stumbling block, because you have to watch your code crash a few times until you have everything in place, particularly when you ''use now, import later''. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10569#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10569: Optionally treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ertes): I'm using `-W` and `-fdefer-typed-holes`. Now ''any'' out of scope variable will cause my program to crash at run-time rather than just telling me that something is out of scope. Since I often have a lot of pending warnings to deal with, I don't see the scope warnings before run- time, and then it can take arbitrarily long to pop up, and I have to start the development cycle all over. Holes (a development tool) and scope errors (a programmer mistake) are fundamentally different things, and treating them as the same massively disrupts my workflow. In fact, after I explained this phenomenon in #haskell on Freenode, we first thought it's a GHC bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10569#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10569: Optionally treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ertes): Simon, but `-fdefer-typed-holes` is a very useful development tool, and when I enable that flag, I'm expecting underscored identifiers to behave differently. Let me just say that ''for me'' this new feature is more of a stumbling block than a useful tool, and there are two ways to fix it: to make it optional, or to implement #12157 (warning priorities). I'm fine with these errors being warnings, as long as I can at least make them show up at the top. "Not in scope" errors are genuine errors in my workflow. Don't get me wrong: I'm in favour of turning as many errors as possible into warnings, but since we don't have a system to prioritise warnings right now, some things should better stay errors. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10569#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10569: Optionally treat an out-of-scope variable like a typed hole -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. I'm fine with having a new flag. Does someone feel like implementing a patch? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10569#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler