- ghc-tickets - Haskell.org

[GHC] #16059: checkValidType is defeated by a type synonym
by GHC 17 Jan '19

17 Jan '19

#16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC throws an error message on this code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where f :: forall b (a :: Eq b => b). Int f = 42 }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20181211: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:6: error: • Illegal constraint in a kind: Eq b => b • In the type signature: f :: forall b (a :: Eq b => b). Int | 6 | f :: forall b (a :: Eq b => b). Int | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} However, it does //not// throw an error message if you hide `Eq b => b` behind a type synonym, as the following variant of the code above is accepted: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where type Foo b = Eq b => b f :: forall b (a :: Foo b). Int f = 42 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #16114: strange "instance .. => .. => .. where ..."
by GHC 17 Jan '19

17 Jan '19

#16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- I don't understand what's happening here: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Prelude> data T a Prelude> instance Eq a => Eq a => Eq (T a) where (==) = undefined <interactive>:2:10: error: • Class ‘Eq’ does not have a method ‘==’ • In the instance declaration for ‘Eq (T a)’ }}} Is that even syntactically correct? (ghc-8.4.4 says "malformed instance") If so, then I'd assume that `A => B => C` means `A && B => C`, that is, `(A,B) => C` in this case, but it does not, since this works: {{{ instance (Eq a, Eq a)=> Eq (T a) where (==) = undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables
by GHC 17 Jan '19

17 Jan '19

#16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- This doesn't typecheck on GHC HEAD: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T a b instance C (Maybe a) where type forall b. T (Maybe a) b = Either a b }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:3: error: The RHS of an associated type declaration mentions out-of-scope variable ‘a’ All such variables must be bound on the LHS | 9 | type forall b. T (Maybe a) b = Either a b | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But it ought to. `a` isn't out of scope at all—it's bound by the class head `instance C (Maybe a)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16096: let x = ... and x = ... are not the same in GHCi
by GHC 17 Jan '19

17 Jan '19

#16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 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: -------------------------------------+------------------------------------- With #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer: {{{ ~ $ ghci -ddump-bcos GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help ... λ:1> let x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_s1vF = ... in ... bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 PUSH_L 0 PUSH_G GHC.Types.True PACK : 2 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_L 0 PUSH_APPLY_P PUSH_G GHC.Base.returnIO SLIDE 3 3 ENTER λ:2> x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO x1_r1wJ#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool) bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 ENTER ProtoBCO Ghci2.x#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1wJ bitmap: 0 [] PUSH_G x1_r1wJ PUSH_G GHC.Types.True PACK : 2 ENTER ... }}} Expected behavior: these two should generate the same byte code, and should be subject to same checks (e.g. for shadowing). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16200: Mechanical checking of submodule versions for releases
by GHC 17 Jan '19

17 Jan '19

#16200: Mechanical checking of submodule versions for releases -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | 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: -------------------------------------+------------------------------------- In the past there have been a few cases where we have put out GHC releases which have shipped with submodule versions which do not correspond with a released package version (e.g. #16199). This should never happen. In principle the output of `git submodule` should be checked before a release is cut to ensure that all submodules point to tags. However, in practice this has proved to be insufficient due to two sources of false-positives: 1. our old mirroring infrastructure often failed to pick up tags 2. often we get away with a mere Hackage revision, which typically aren't tagged Thankfully (1) should no longer be a problem with the move to GitLab. Moreover, now since we finally have reliable CI we can automate release creation. However, it's not entirely clear how to reliably verify the consistency of submodules in light of problem (2). Unfortunately, it's quite tricky to avoid due to the existence of -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15905: Data familes should end in Type
by GHC 17 Jan '19

17 Jan '19

#15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Currently we allow {{{ data family Fix (f :: Type -> k) :: k }}} with a ‘k’ in the right-hand corner. See `Note [Arity of data families]` in `FamInstEnv`. That seems attractive because we can then have {{{ data instance Fix (f :: Type -> Type -> Type) (x :: Type) = MkFix2 (f (Fix f x) x) }}} But what about this? {{{ type family F a type instance F Int = Type -> Type data instance Fix (f :: Type -> F Int) (x :: Type) = … }}} The type inference engine (tcInferApps) will type the LHS as something like {{{ ((Fix (f :: Type -> F Int)) |> co1) (x |> co2) where co1 :: F Int ~ Type co2 :: Type ~ F Int }}} But the LHS of a family axiom has to look like {{{ F t1 t2 … tn }}} not {{{ ((F t1 |> co) t2 t3) |> co4) …tn }}} with casts in the way. So that LHS must be rejected. And it’s very hard to see how to accept the first example while (predictably, comprehensibly) rejecting the second. It’d be something like “the kind that instantiates k must have obvious, visible, arrows”. Ugh! And indeed GHC HEAD does accept the first, but rejects the second with the error message {{{ • Expected kind ‘* -> * -> *’, but ‘f :: Type -> F Int’ has kind ‘* -> F Int’ • In the first argument of ‘Fix’, namely ‘(f :: Type -> F Int)’ In the data instance declaration for ‘Fix’ }}} That's clearly bogus: we've specified that `F Int = Type -> Type`. I'm not even sure precisely how it happens, but it must be fragile: a change in solve order, or more aggressive solving might change the behaviour. I don't see how to solve this. I propose instead to require data family kinds to end in `Type`, not in a type ''variable'' (as we currently allow). I don't know how many people that would affect, but the current state of affairs looks untenable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15873: move to llvm 7 for 8.8.1
by GHC 16 Jan '19

16 Jan '19

#15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15447: Mark the core libraries' internal modules "not-home" instead of "hide"
by GHC 16 Jan '19

16 Jan '19

#15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: haddock | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm often a bit annoyed that I cannot browse the haddocks for internal libraries. It would be nice if `base`, `ghc-prim`, `integer-gmp` and `integer-simple` could follow the example of `containers` and other libraries and offer docs for internal libraries too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16189: ParsedSource (especially module name source span) not available from Source Plugin
by GHC 16 Jan '19

16 Jan '19

#16189: ParsedSource (especially module name source span) not available from Source Plugin -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: GHC API | Version: 8.6.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: -------------------------------------+------------------------------------- As discovered in https://github.com/google/haskell- indexer/pull/89#discussion_r248081268, the `TcGblEnv` received by a Source Plugin doesn't seem to have a way of accessing the SrcSpan of the module name. When having access to the ParsedModule, it contains ParsedSource, which is `Located (HsModule GhcPs)`, whose inner datatype contains `Maybe (Located ModuleName)`, with the location's span pointing to the module name span. From `TcGblEnv` one can access the `ModSummary`, which has a `Maybe HsParsedModule`, but seems to be `Nothing` practically. I know this is a minor nit, but all other declarations are accessible by the source plugin so far, just this bit seems missing. Without this, haskell-indexer has to resort to source-code heuristics to get the module name span. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13191: Make liftA2 a method of Applicative
by GHC 16 Jan '19

16 Jan '19

#13191: Make liftA2 a method of Applicative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D3031 | Wiki Page: -------------------------------------+------------------------------------- Some functors support implementations of `liftA2` that are considerably faster than the usual definition. Furthermore, some people see `liftA2` as more intuitive and fundamental to the idea of `Applicative` than `<*>` is. This has been discussed on the libraries list in https://mail.haskell.org/pipermail/libraries/2017-January/027579.html and (as an official proposal) in https://mail.haskell.org/pipermail/libraries/2017-January/027612.html. All who expressed an opinion favored the proposal. One (David Menendez) specified that his support was weak. The others (Conal Elliot, Kris Nuttycombe, Wren Romano, Bardur Arantsson, and Mario Blažević) either supported the proposal strongly or merely indicated they were "+1". Conal Elliot wrote: [[BR]] [[BR]] > +1. > > I also sometimes define a specialized `liftA2` and then use it to define > `(<*>)`, which then gets used to define the real `liftA2`. > > I think of `liftA2` as playing a role similar to `foldMap` and `traverse`, while > `(<*>)` corresponds to `fold` and `sequenceA`. The first three self- compose > nicely: `liftA2.liftA2.liftA2`, `foldMap.foldMap.foldMap`, and > `traverse.traverse.traverse`. With functor composition, it's so much nicer to > write `liftA2.liftA2` (in the style of `Functor`, `Foldable`, and `Traversable`) > rather than `liftA2 (<*>)`. [[BR]] Wren Romano wrote [[BR]] [[BR]] > I'm also all for adding liftA2 to the class and have noticed this > inefficiency/asymmetry when working on the class hierarchies for other > languages [[BR]] Kris NuttyCombe wrote [[BR]] [[BR]] > I'm in favor of this change. From my perspecive, liftA2 is actually the > fundamental Applicative operation, an <*> is merely a convenient > isomorphism. When I'm teaching, showing the symmetry between the following > always seems to help students: > > fmap :: (a -> b) -> f a -> f b > liftA2 :: (a -> b -> c) -> f a -> f b -> f c > flip (>>=) :: (a -> f b) -> f a -> f b > > <*> is obviously exceptionally useful in practice. But liftA2 seems like the > more essential shape of that operation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2