[GHC] #10411: Neighbour let-bindings are not reported as relevant
#10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{
:set -fno-max-relevant-binds let a = True; b = _ in undefined
<interactive>:3:19: Found hole ‘_’ with type: t1 Where: ‘t1’ is a rigid type variable bound by the inferred type of b :: t1 at <interactive>:3:15 Relevant bindings include b :: t1 (bound at <interactive>:3:15) it :: t (bound at <interactive>:3:1) In the expression: _ In an equation for ‘b’: b = _ In the expression: let a = True b = _ in undefined }}} Somehow a is not there, even though b itself is. Tested with 7.8.3 and 7.10.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10411 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | 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 simonpj): GHC reports an enclosing binding as "relevant" if its type mentions a type variable used in the type of the hole. Here we have `b :: forall t1.t1`, whereas `a::Bool`. So `a` is not mentioned as relevant. You obviously wish that it was. How could we define "relevant" better? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10411#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | 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 Feuerbach): How about including all local bindings that are in scope at that point? The motivation is: 1. Some of the local bindings will likely be used to fill in the hole 2. There are typically not too many of them, so the output will stay relevant (as opposed to including global bindings, too) 3. The feature is especially useful for local bindings, since getting their type requires a bit of extra work (again, as opposed to global bindings) I don't have an opinion on whether this should replace or be added to the current type-based algorithm which you describe (and which I wasn't aware of until now). Although if I understand the current algorithm correctly, it will only ever report bindings from the current declaration (since type variables cannot be shared across declarations), so in that case my proposal seems to be about simply lifting the type-based restriction. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10411#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | 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 simonpj):
How about including all local bindings that are in scope at that point?
I wouldn't be against that. I assume it would ''replace'' the current algorithm, at least for holes. (After all, it'll report a superset of the former algorithm.) What do others think? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10411#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | 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: -------------------------------------+------------------------------------- Changes (by gershomb): * cc: JohnWiegley, gershomb (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10411#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10411: Neighbour let-bindings are not reported as relevant -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | 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 gershomb): Sorry for the noise, this is a test comment to poke the trac mail system. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10411#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC