January 2017 - ghc-tickets

[GHC] #13065: Prohibit user-defined Generic and Generic1 instances
by GHC 20 Jan '17

20 Jan '17

#13065: Prohibit user-defined Generic and Generic1 instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: Generics | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- User-defined `Generic` and `Generic1` instances are problematic. === They are susceptible to breakage === Some details of the classes may change between GHC versions, and indeed have done so in the past. User-defined instances are likely to break in the face of various such "internal" changes. This is one reason why `Data.Sequence`, for example, does not have a `Generic` instance. === They require potentially-expensive consistency checks === GHC cannot assume that every type has at most one `Generic` and `Generic1` instance, so it needs to look for possible alternatives at instance resolution time. According to Simon (and maybe also Simon), this may be partly responsible for the performance regressions seen in Phab:D2899. === Downsides === Prohibiting user-defined instances does have some costs. Suppose a type was originally defined concretely, exposing its constructors and a `Generic` instance. The implementer may decide later to make the type abstract, and export pattern synonyms to retain the same interface. But the `Generic` instance will either change or disappear. Someone relying on that instance could be in trouble. If the instance disappears, they'll be forced to write code by hand that they didn't need to before. If it changes, their code may change its behavior unexpectedly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13151: Make all never-exported IfaceDecls implicit
by GHC 19 Jan '17

19 Jan '17

#13151: Make all never-exported IfaceDecls implicit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the representation of an instance in an interface file. It is always associated with a DFun, but the DFun is stored as a separate IfaceDecl. You might wonder if it's possible for an IfaceClsInst to refer to an externally defined DFun, or if it's possible to have a DFun but no IfaceClsInst associated with it. The current ClsInst representation won't tell you, but in fact, it's impossible. For example, DFuns are manually added to the type environment by TidyPgm, which literally goes through the list of ClsInsts to pull out the set of DFunIds which need to be added to the TypeEnv. This all seems horribly indirect. Why not just *embed* the IfaceDecl describing the DFun inside IfaceClsInst, and treat the DFun as an "implicit TyThing"? This makes it clear that the instance declaration canonically defines the DFun. To do this, we have to expand our idea of implicit TyThings; at the moment, only a TyThing can be associated with implicit TyThings. With this change, instances and family instances can also be associated with implicit TyThings. But this doesn't seem like too much. Why does this matter? I was cleaning up some code in Backpack, and I noticed that I had written some very complicated things to handle DFuns and coercion axioms, because they were indirected through a Name, even though morally they should have been "implicit"-like things. The proposed refactor here would solve this correctness problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13145: Documentation shouldn't call things functions that aren't functions
by GHC 19 Jan '17

19 Jan '17

#13145: Documentation shouldn't call things functions that aren't functions -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example, in the [Prelude](https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html) docs we have a section called "Input functions" in which only one of the four values is a function: {{{ getChar :: IO Char getLine :: IO String getContents :: IO String interact :: (String -> String) -> IO () }}} Referring to non-function values (particularly of type `IO`) as "functions" is often a sign that beginners haven't fully grasped some concepts about purity, so I think it's important to clean up our own language. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13145> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12809: TYPE 'UnboxedTupleRep is still a lie
by GHC 19 Jan '17

19 Jan '17

#12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 new scheme for describing kinds of types with values with `TYPE :: RuntimeRep -> Type` is a large improvement on the old way of using kind `#` for all unlifted types. In particular, the new scheme differentiates between the kind of `Int#` and `Float#`, for example, because these have different calling conventions. This is Good. But there is still a lie left in the whole scheme: `UnboxedTupleRep`, which covers all unboxed tuples. Of course, unboxed tuples of different arities and contents have different calling conventions, so these should be distinguished at the kind level. Simon and I have cooked up a new scheme to handle this, summarized in these definitions: {{{#!hs TYPE :: RuntimeRep -> Type -- highly magical, just as before type RuntimeRep = [UnaryRep] -- this bit is the new part data UnaryRep = PtrRepLifted -- like the old RuntimeRep type | PtrRepUnlifted | IntRep | ... type Lifted = '[PtrRepLifted] -- a very common case type Type = TYPE Lifted -- good old Type }}} The `UnaryRep` type is the big sum of all possible representations, just like the `RuntimeRep` of today. It drops `VoidRep` and `UnboxedTupleRep`, however. The interpretation of this is that the kinds now include a ''list'' of unary representation forms. A "unary representation" corresponds to what we might expect to store in one machine register at runtime. Unboxed tuples naturally have a variable number of associated unary reps: this is precisely what an unboxed tuple means. It also baldly states that the unary unboxed tuple is identical (at runtime) to the thing in the tuple (which is correct) and also allows us to remove the runtime distinction between `(# #)` and `Void#`, which now both have kind `TYPE '[]`. (Indeed, perhaps we should just say `type Void# = (# #)`.) This will not be backward compatible with GHC 8.0. But I'm OK with this, as any user access to these features requires importing internal modules, and it seems quite painful to try to come up with a migration story here for an experimental feature. Patch will be written this weekend, with any luck. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12987: Core lint error with levity polymorphism
by GHC 19 Jan '17

19 Jan '17

#12987: Core lint error with levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Types Prelude GHC.Types> :set -XTypeInType Prelude GHC.Types> class NUM (a :: TYPE rep) where add :: a -> a -> a Prelude GHC.Types> }}} works, but with `-dcore-lint` I get a core lint error {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Types Prelude GHC.Types> :set -XTypeInType Prelude GHC.Types> :set -dcore-lint Prelude GHC.Types> class NUM (a :: TYPE rep) where add :: a -> a -> a *** Core Lint errors : in result of Tidy Core *** <no location info>: warning: In the type ‘forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q’ Ill-kinded argument in type or kind ‘a_a17Q -> a_a17Q’ type or kind ‘a_a17Q -> a_a17Q’ kind: TYPE rep_a17P <no location info>: warning: In the type ‘forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q’ Ill-kinded argument in type or kind ‘a_a17Q -> a_a17Q -> a_a17Q’ type or kind ‘a_a17Q -> a_a17Q -> a_a17Q’ kind: TYPE rep_a17P *** Offending Program *** add [InlPrag=INLINE] :: forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=DmdType <S,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ (rep_a17P :: RuntimeRep)) (@ (a_a17Q :: TYPE rep_a17P)) (tpl_B1 [Occ=Once] :: NUM a_a17Q) -> tpl_B1 `cast` (N:NUM[0] <rep_a17P>_N <a_a17Q>_N :: (NUM a_a17Q :: Constraint) ~R# ((a_a17Q -> a_a17Q -> a_a17Q) :: *))}] add = \ (@ (rep_a17P :: RuntimeRep)) (@ (a_a17Q :: TYPE rep_a17P)) (tpl_B1 :: NUM a_a17Q) -> tpl_B1 `cast` (N:NUM[0] <rep_a17P>_N <a_a17Q>_N :: (NUM a_a17Q :: Constraint) ~R# ((a_a17Q -> a_a17Q -> a_a17Q) :: *)) $trModule1_r18t :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $trModule1_r18t = TrNameS "interactive"# $trModule2_r18D :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $trModule2_r18D = TrNameS "Ghci1"# $trModule :: Module [GblId, Caf=NoCafRefs, Str=DmdType] $trModule = Module $trModule1_r18t $trModule2_r18D $tc'C:NUM1_r18E :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $tc'C:NUM1_r18E = TrNameS "'C:NUM"# $tc'C:NUM :: TyCon [GblId, Caf=NoCafRefs, Str=DmdType] $tc'C:NUM = TyCon 13508714812303496948## 14031386194776682412## $trModule $tc'C:NUM1_r18E $tcNUM1_r18F :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $tcNUM1_r18F = TrNameS "NUM"# $tcNUM :: TyCon [GblId, Caf=NoCafRefs, Str=DmdType] $tcNUM = TyCon 18330307158587089132## 17437587248867430906## $trModule $tcNUM1_r18F *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11736: Allow unsaturated uses of unlifted types in Core
by GHC 19 Jan '17

19 Jan '17

#11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently Core Lint checks for unsaturated uses of unlifted types in . These are easily produced in the new type-indexed `Typeable` scheme. For instance, consider solving for `Typeable # (Array# Int)`: * We decompose the application into wanteds `Typeable (* -> #) Array#` and `Typeable * Int` * We construct dictionaries for both, giving us a term `typeRepArray# :: TypeRep (* -> #) Array#` While nothing seems to blow up with this patch, {{{#!patch diff --git a/compiler/coreSyn/CoreLint.hs b/compiler/coreSyn/CoreLint.hs index 99625c9..2c401de 100644 --- a/compiler/coreSyn/CoreLint.hs +++ b/compiler/coreSyn/CoreLint.hs @@ -1040,7 +1040,7 @@ lintType ty@(TyConApp tc tys) = lintType ty' -- Expand type synonyms, so that we do not bogusly complain -- about un-saturated type synonyms - | isUnliftedTyCon tc || isTypeSynonymTyCon tc || isTypeFamilyTyCon tc + | isTypeSynonymTyCon tc || isTypeFamilyTyCon tc -- Also type synonyms and type families , length tys < tyConArity tc = failWithL (hang (text "Un-saturated type application") 2 (ppr ty)) }}} I otherwise have no reason to believe that this is safe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12973: No levity-polymorphic arguments
by GHC 19 Jan '17

19 Jan '17

#12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As discussed in our [http://cs.brynmawr.edu/~rae/papers/2017/levity/levity.pdf draft paper] on levity polymorphism, you cannot have a levity-polymorphic argument. Here is an example: {{{#!hs {-# LANGUAGE RebindableSyntax, TypeInType, ExplicitForAll #-} module Bug where import qualified Prelude as P import GHC.Exts class Num (a :: TYPE r) where (+) :: a -> a -> a fromInteger :: P.Integer -> a foo :: forall (a :: TYPE r). Num a => a foo = 3 + 4 }}} HEAD panics in `kindPrimRep`, but the code should be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13146: Doc for RealWorld refers to non-existent "ptrArg"
by GHC 18 Jan '17

18 Jan '17

#13146: Doc for RealWorld refers to non-existent "ptrArg" -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The haddock for `RealWorld` says: > `RealWorld` is deeply magical. It is ''primitive'', but it is not ''unlifted'' (hence `ptrArg`). We never manipulate values of type `RealWorld`; it's only used in the type system, to parameterise `State#`. The "(hence `ptrArg`)" doesn't seem to make any sense. There is no identifer named `ptrArg` anywhere in the GHC repository. Is this a typo, or a reference to something that no longer exists? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11789: Flag suggestion does not always work
by GHC 18 Jan '17

18 Jan '17

#11789: Flag suggestion does not always work -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Driver | Version: 8.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Usually, GHC is very helpfully telling me about misspelled flags, but sometimes it fails. Did not yet look deeper, but when I wrote `-fppr- cols=1000` it did not suggest `-dppr-cols=1000`. I am not sure if this is due to the `=` or whether it branches on `-f` vs. `-d` earlier. This surely can be improved! Likely newcomer-friendly.. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13136: Foreign.C.Types does not have a CBool type
by GHC 18 Jan '17

18 Jan '17

#13136: Foreign.C.Types does not have a CBool type -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- We should add a `CBool` corresponding to C99's `bool`. Using Haskell's `Bool` can lead to unexpected errors, because it corresponds to `HsBool`, which is word-sized whereas C99 `bool` is unsigned char. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3