December 2015 - ghc-tickets

[GHC] #11169: Remove the word "skolem" from user error messages
by GHC 08 Dec '15

08 Dec '15

#11169: Remove the word "skolem" from user error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Skolem variables are not, as best I can tell, part of the type system; they are part of the implementation of the type checking algorithm. As such, it seems inappropriate to mention them in error messages. Instead, the error messages should explain things at the Haskell level. {{{ Couldn't match expected type ‘t’ with actual type ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by... }}} I'd much rather see an explanation using words like "existentially quantified" and "right-hand side of a pattern match". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11169> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar.
by GHC 08 Dec '15

08 Dec '15

#11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Code: {{{#!hs module B where aaa x = aaa x bbb = aaa 1 }}} === In the renamed AST The reference is to the exported aaa (span 3:1-3, sort WiredIn), which is as expected (by me at least). (dump with ghc-dump-tree with some local mods compiled by GHC 7.10.2) {{{ (HsApp (L /tmp/B.hs:3:9-11 (HsVar here ------------> { n_loc = /tmp/B.hs:3:1-3 <----------- here , n_sort = { WiredIn = Module main B } , VarName = aaa })) (L /tmp/B.hs:3:13 (HsVar { n_loc = /tmp/B.hs:3:5 , n_sort = Internal , VarName = x }))))) }}} === In the typechecked AST Here the call target changes to internal (as described by the monomorphic binding abe_mono). {{{ (HsApp (L /tmp/B.hs:3:9-11 (HsVar { varType = { t -> t = FunTy (TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t }) (TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t }) } here -------------> , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , VarName = aaa })) (L /tmp/B.hs:3:13 (HsVar { varType = { t = TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t } } , n_loc = /tmp/B.hs:3:5 , n_sort = Internal , VarName = x }))))) }}} (Just remarking, that GHC 7.8 and 7.10 seem to have improved the span ranges a bit over 7.6, so trying to reproduce with 7.6 the span will be the shorter one on the function name, but the sort will still be the internal). Note that referring the function in a non-recursive way seem to refer to the exported (abe_poly) binding. From the perspective of a tooling writer, this difference is somewhat surprising, and is a case to be handled separately. * Is there a fundamental reason why the reference changes after Typechecking? * Since I'm not deeply familiar with the AST, I might miss something. Does it happen in other cases too that sometimes abe_poly is referred, sometimes the abe_mono? If so, what is the rule? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11177: panic! tc_hs_type: record
by GHC 08 Dec '15

08 Dec '15

#11177: panic! tc_hs_type: record --------------------------------+--------------------------------- Reporter: apanagio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- when trying to compile a file where "deriving" was missing from a data type got the message: ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): tc_hs_type: record Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug the source file is: {{{#!hs data Epafi = Epafi { } (Show) main :: IO () main = do print "hello" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation
by GHC 08 Dec '15

08 Dec '15

#10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: pattern | Type of failure: None/Unknown synonyms | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Suppose I have the following two modules. {{{#!hs {-# LANGUAGE PatternSynonyms #-} module A where data A = A2 Int Int pattern A1 a <- A2 a _ where A1 a = A2 a 0 }}} {{{#!hs module B where import A ( A(..) ) a = A1 0 }}} When I try to compile `B.hs` I get an error because `A1` is unbound in module `B`. {{{ $ ghc --make B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) B.hs:5:5: Not in scope: data constructor ‘A1’ Perhaps you meant ‘A2’ (imported from A) }}} The issue is that the import `A(..)` brings all of `A`s data constructors and accessors into scope, but not any associated pattern synonyms. Instead I have to enable `PatternSynonyms` in module `B` (or just import everything from `A`). {{{#!hs {-# LANGUAGE PatternSynonyms #-} module B where import A ( A(..), pattern A1 ) a = A1 0 }}} I'd like to propose that we extend the semantics of the `A(..)` import/export notation to include any associated pattern synonyms. I think this is in line with the spirit of `PatternSynonyms`, that the extension should allow internal refactoring without causing API breakage, and that the extension should only need to be enabled to *define* pattern synonyms. FYI, this issue does appear in the wild, I ran into it while working on https://phabricator.haskell.org/D861 and had to modify two import lists in Cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10653> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

Re: [GHC] #5273: error and undefined should print a location
by GHC 08 Dec '15

08 Dec '15

#5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Rev(s): Phab:D861 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"9f4ca5afaccc8a397d8ee91b5423a9c2fcd151ce/ghc" 9f4ca5a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9f4ca5afaccc8a397d8ee91b5423a9c2fcd151ce" Associate ErrorCall pattern with ErrorCall type This way, import Control.Exception (ErrorCall(ErrorCall)) or import Control.Exception (ErrorCall(..)) work as expected, and import the `ErrorCall` compatibility pattern as well. When #5273 was implemented, it wasn't possible yet to associated patterns with their types (see #10653). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1588 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5273#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5972: option to suppress (Monomorphic) record selector functions
by GHC 07 Dec '15

07 Dec '15

#5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: records 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 adamgundry): * owner: adamgundry => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5972#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1?
by GHC 07 Dec '15

07 Dec '15

#7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 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 RyanGlScott): The changes Pedro was alluding to involving `DataKinds` have now been implemented (#9766), so that's no longer holding this back. It would be interesting to talk about the pros and cons of changing `Rec1 f` to `f :.: Par1` The obvious pro is that is removes a redundant representation type, making `(:.:)` the sole way to talk about type constructors being applied to the type parameter. I also suspect that this change would make #8516 easier, but that's a different story. There are two cons that I can see: 1. All code that declares instances for `Rec1` would eventually have to be changed. We have a much better story for deprecation than we used to, though, so this isn't a dealbreaker. 2. `Generic1` instances involving `Rec1` have different instance heads than instances involving `(:.:)`. To be more specific, consider this data type: {{{#!hs newtype T1 a = T1 (T2 a) deriving Generic1 }}} Right now, this would be derived `Generic1` instance: {{{#!hs instance Generic1 T1 where type Rep1 T1 = D1 ('MetaData "T1" "Module" "package" 'True) (C1 ('MetaCons "T1" 'PrefixI 'False) (S1 'NoSelector (Rec1 T2))) from1 (T1 a) = M1 (M1 (M1 (Rec1 a))) to1 (M1 (M1 (M1 a))) = T1 (unRec1 a) }}} But with this proposal, it would be this: {{{#!hs instance Generic1 T1 where type Rep1 T1 = D1 ('MetaData "T1" "Module" "package" 'True) (C1 ('MetaCons "T1" 'PrefixI 'False) (S1 'NoSelector (T2 :.: Par1))) from1 (T1 a) = M1 (M1 (M1 (Comp1 (fmap Par1 a)))) to1 (M1 (M1 (M1 a))) = T1 (fmap unPar1 (unComp1 a)) }}} There's one very important difference here. The latter instance requires that `T2` is a `Functor` instance, whereas the former instance does not! It would be interesting to know if this would prevent some datatypes in the wild from being `Generic1` instances. For example, suppose `newtype T2 a = T2 (a -> Int)`. Then we couldn't make `T2` a `Functor`, and thus we couldn't make `T1` `Generic1`! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7492#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 07 Dec '15

07 Dec '15

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Rev(s): Phab:D211 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: simonpj => bgamari -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 07 Dec '15

07 Dec '15

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Rev(s): Phab:D211 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this ticket is now done (as part of the "wildcard refactor" patch (1e041b7382b6aa329e4ad9625439f811e0f27232), except that we should remove `-fwarn-context-quantification` altogether (according to comment:20), or deprecate it. It already does nothing. Ben: could you do this, and close? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10444: Tex.Read.Lex.lex broken
by GHC 07 Dec '15

07 Dec '15

#10444: Tex.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ Prelude> lex "&) = mempty" [("&",") = mempty")] Prelude> lex "∘) = mempty" [] }}} I traced this problem to Text.Read.Lex.lex -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15