- ghc-tickets - Haskell.org

[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 08 Dec '15

08 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 08 Dec '15

08 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

[GHC] #8245: ghc-pkg list prints packages in non-alphabetical order
by GHC 07 Dec '15

07 Dec '15

#8245: ghc-pkg list prints packages in non-alphabetical order ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- Instead, it prints the ones with the smallest version first. That does not make much sense. I will attach a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names
by GHC 07 Dec '15

07 Dec '15

#10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Trying to help @mpickering with Phab:D1258, I looked at the code in `tcRnSrcDecls` and was surprised to see that exports are renamed after this function is complete. This didn't make any sense to me. And, indeed, it's wrong, witness by this example: {{{ {-# OPTIONS_GHC -fwarn-missing-exported-sigs #-} module Bug (Data.List.intercalate, x) where import qualified Data.List intercalate = True x :: Bool x = intercalate }}} This produces {{{ Bug.hs:7:1: Warning: Top-level binding with no type signature: intercalate :: Bool }}} This warning should not be emitted. I'm not all that concerned about this scenario biting in the wild, but it suggests that refactoring this code is a good thing, and not something Phab:D1258 should take pains to avoid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11028: Refactor ConDecl
by GHC 07 Dec '15

07 Dec '15

#11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most part, `HsSyn` directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type {{{ data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ‘::’ , con_doc :: Maybe LHsDocString , con_old_rec :: Bool } | ConDeclH98 { con_name :: Located name , con_implict :: HsImplicitBndrs () -- ^ Implicit binders, added by renamer , con_qvars :: Maybe [LHsTyVarBndr name] -- User-written foralls (if any) , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) }}} Note that * For GADTs, just keep a type. That's what the user writes. (NB: `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } -> T` * `con_qvars` and `con_cxt` are both `Maybe` because they are both optional (the `forall` and the context of an existential data type) * The `con_old_rec` is a warning thing for GADTs (see current source code) This ticket is just to track the thought and invite feedback. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48