[GHC] #8450: can't match type Bool with (), but shouldn't have to
#8450: can't match type Bool with (), but shouldn't have to ------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following (definitely type-incorrect) file: {{{ {-# LANGUAGE ScopedTypeVariables #-} runEffect :: Either Bool r -> r runEffect = undefined run :: forall a. a run = runEffect $ (undefined :: Either a ()) }}} produces the following error: {{{ test.hs:7:7: Couldn't match type `Bool' with `()' Expected type: a Actual type: () In the expression: runEffect $ (undefined :: Either a ()) In an equation for `run': run = runEffect $ (undefined :: Either a ()) }}} This is strange because one of the two types it claims it can't unify (Bool) doesn't appear in either the expected or actual type. Note that removing the ($) gets a different error message that makes it a bit more clear what's going on: {{{ test.hs:7:18: Couldn't match type `Bool' with `()' Expected type: Either Bool a Actual type: Either a () In the first argument of `runEffect', namely `(undefined :: Either a ())' In the expression: runEffect (undefined :: Either a ()) In an equation for `run': run = runEffect (undefined :: Either a ()) }}} So it seems it's trying to unify Bool and () because it's unifying both a with Bool and a with (); however, the usual comments about rigid type variables aren't there, which makes even this error message a bit confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8450: can't match type Bool with (), but shouldn't have to -------------------------------------+------------------------------------ Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by carter): I hit this problem or something very very close to it, earlier this week. Though in my case it was for type correct code that i had to hoist out as a top level definition to type check.. I'll see if i can repro it in a smaller example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8450: can't match type Bool with (), but shouldn't have to -------------------------------------+------------------------------------ Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * cc: dimitris@… (added) Comment: Nice example. (The rest of this is cryptic comments mainly for Dimitrios.) The issue is this. We have a skolem 'a', and two constraints {{{ [w} a ~ Bool [w] a ~ () }}} But because we rewrite wanteds with wanteds, we rewrite to {{{ [w] Bool ~ () }}} which is really quite unhelpful. I'm beginning to wonder: what would happen if we never rewrote a wanted with another wanted? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8450: can't match type Bool with (), but shouldn't have to -------------------------------------+------------------------------------ Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"06aac68dee100b21dc7d304fa90d9baa423507a0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="06aac68dee100b21dc7d304fa90d9baa423507a0" Refactor the constraint solver (again!) There are three core changes here: a) In the constraint-solver pipeline. Given a work-item 'wi', the old scheme was: let relevant = getRelevantInerts wi interact 'wi' with each constraint in 'relevant' Bu now we have a single step interact 'wi' with the inert-set This turns out to avoid duplication, between getRelevantInerts (which needs to know which are relevant) and the interact step. Simpler, cleaner. This in turn made it sensible to combine the 'spontaneous solve' stage into the 'interact with inerts' stage. b) Wanteds are no longer used to rewrite wanteds. See Trac #8450. This in turn means that the inert set may have - many CFunEqCans with the same LHS - many CTyEqCans with the same LHS Hence the EqualCtList in teh domain of inert_eqs and inert_funeqs c) Some refactoring of the representation of the inert set, Notably inert_dicts and inert_funeqs are indexed by Class and TyCon respectively, so we can easily get all the constraints relevant to that class or tycon There are many knock on effects! This started as a small job but I ended up doing qite a lot. Some error messages in the test suite really did improve as a result of (b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8450: can't match type Bool with (), but shouldn't have to -------------------------------------+------------------------------------ Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"8c88d0a9b205a31b1708a7069c4aa417373f9ac3/testsuite"]: {{{ #!CommitTicketReference repository="testsuite" revision="8c88d0a9b205a31b1708a7069c4aa417373f9ac3" Test Trac #8450 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8450: can't match type Bool with (), but shouldn't have to ------------------------------------------------+-------------------------- Reporter: dmwit | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T8450 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T8450 * resolution: => fixed Comment: Thank you for the provocation. Things are much better now. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#8450: can't match type Bool with (), but shouldn't have to ------------------------------------------------+-------------------------- Reporter: dmwit | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: typecheck/should_fail/T8450 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"7881488201629aa1ab36e3e0fbeb4d7b4b85bd91/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7881488201629aa1ab36e3e0fbeb4d7b4b85bd91" A raft of changes driven by Trac #8540 The root cause of #8450 is that the new Template Haskell story, with the renamer doing more of the work of Template Haskell, wasn't dealing correctly with the keepAlive problem. Consider g = ..blah... f = [| g |] Then f's RHS refers to g's name but not to g, so g was being discarded as dead code. Fixing this sucked me into a deep swamp of understanding how all the moving parts of hte new Template Haskell fit together, leading to a large collection of related changes and better documentation. Specifically: * Instead of putting the TH level of a binder in the LocalRdrEnv, there is now a separate field tcl_th_bndrs :: NameEnv (TopLevelFlag, ThLevel) in the TcLclEnv, which records for each binder a) whether it is syntactically a top-level binder or not b) its TH level This deals uniformly with top-level and non-top-level binders, which was previously dealt with via greviously-delicate meddling with Internal and External Names. Much better. * As a result I could remove the tct_level field of ATcId. * There are consequential changes in TcEnv too, which must also extend the level bindings. Again, more clarity. I renamed TcEnv.tcExtendTcTyThingEnv to tcExtendKindEnv2, since it's only used during kind inference, for (AThing kind) and APromotionErr; and that is relevant to whether we want to extend the tcl_th_bndrs field (no). * I de-crufted the code in RnEnv.extendGlobalRdrEnv, by getting rid of the qual_gre code which said "Seems like 5 times as much work as it deserves!". Instead, RdrName.pickGREs makes the Internal names shadow External ones. * I moved the checkThLocalName cross-stage test to finishHsVar; previously we weren't doing the test at all in the OpApp case! * Quite a few changes (shortening the code) in the cross-stage checking code in TcExpr and RnSplice, notably to move the keepAlive call to the renamer One leftover piece: * In TcEnv I removed tcExtendGhciEnv and refactored tcExtendGlobalTyVars; this is really related to the next commit, but it was too hard to disentangle. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC