January 2019 - ghc-tickets

[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

[GHC] #16196: Update README.md to reflect gitlab
by GHC 16 Jan '19

16 Jan '19

#16196: Update README.md to reflect gitlab -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- https://gitlab.haskell.org/ghc/ghc's [https://gitlab.haskell.org/ghc/ghc/blob/master/README.md README.md] still points to > Check out the source code from git > {{{ > $ git clone --recursive git://git.haskell.org/ghc.git > }}} there are probably other other places that need to be updated, marking as *newcomer* -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16101: Write a nix expression to enter a shell with specified build artifact
by GHC 16 Jan '19

16 Jan '19

#16101: Write a nix expression to enter a shell with specified build artifact -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- It should be quite straightforward to write a nix expression which is parameterised by a CI job which downloads the artifact and enters into a nix shell which provisions that version of GHC. To be precise, consider the recent job: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427. It built these artifacts: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427/artifacts/browse We should download the bindist and patch it suitably so it works like a normal GHC release. Some inspiration can probably be drawn from the scripts that Ben wrote for the head.hackage repo: https://github.com/hvr/head.hackage/blob/master/default.nix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16192: Simplifier does not preserve dependency ordering of the program
by GHC 16 Jan '19

16 Jan '19

#16192: Simplifier does not preserve dependency ordering of the program -------------------------------------+------------------------------------- Reporter: osa1 | 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 noticed this some time ago, but I thought this is expected, because there's a comment in CoreLint that mentions this: {{{ lintCoreBindings dflags pass local_in_scope binds = initL dflags flags in_scope_set $ addLoc TopLevelBindings $ lintLetBndrs TopLevel binders $ -- Put all the top-level binders in scope at the start -- This is because transformation rules can bring something -- into use 'unexpectedly' ... }}} However talking to SPJ today he mentioned that in Core we should actually preserve dependency ordering, hence this ticket. I'll update with a reproducer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15602: PAP invariant of pointer tagging does not hold
by GHC 16 Jan '19

16 Jan '19

#15602: PAP invariant of pointer tagging does not hold -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15508, #13767 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The PAP invariant of pointer tagging says > the PAP entry code jumps to the function's entry code, so it must have a tagged pointer to the function closure in R1. We therefore assume that a PAP always contains a tagged pointer to the function closure. (from https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/Point…) As discovered while debugging #15508, this currently does not hold. I tried to fix this in one PAP allocation site in Phab:D5051 but it somehow broke another test. We should review all PAP allocation sites and make sure the invariant holds, and then fix any bugs that this fix reveals. Relevant commits: - 6015a94f9108a502150565577b66c23650796639: Implements pointer tagging - f9c6d53fe997f1c560cda6f346f4b201711df37c: Fixes a PAP allocation site (#13767) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5
by GHC 16 Jan '19

16 Jan '19

#16127: Panic: piResultTys1 in compiler/types/Type.hs:1022:5 -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I apologize in advance for a non-minimised repro. The panic (with a small `-ddump-tc-trace` excerpt, but full log also attached): {{{ tcPolyExprNC Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcSkolemise tcInferId voc_a4TB2 :: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) tcCheckId voc_a4TB2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tcWrapResult Actual: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) Expected: Check{Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2])} tc_sub_type_ds ty_actual = Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ty_expected = Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) deeply_instantiate final subst origin: arising from a use of ‘voc_a4TB2’ type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) new type: Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) subst: [TCvSubst In scope: InScope {i_a4TMf} Type env: [] Co env: []] u_tys tclvl 2 Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) arising from a type equality Vocab i_a4TMf[sk:1] (Present * * i_a4TMf[sk:1]) ~ Vocab * (k_a4TNy[tau:2] -> Constraint) i_a4TNv[tau:2] (Present * k_a4TNy[tau:2] i_a4TNv[tau:2]) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): piResultTys1 * [i_a4TNv[tau:2], Present * k_a4TNy[tau:2] i_a4TNv[tau:2]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1022:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Repro (requires Nix & some download time, provides hard repro guarantees in return): {{{ $ git clone https://github.com/deepfire/holotype $ cd holotype $ git reset --hard 7e9f5099eea2080f57205267291eeec50ae4b68a $ nix-shell [nix-shell:~/holotype]$ make }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12045: Visible kind application
by GHC 16 Jan '19

16 Jan '19

#12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've wanted this for a while {{{ ghci> :kind (:~:) (:~:) :: k -> k -> Type }}} {{{ ghci> :kind (:~:) @(Type -> Type) (:~:) @(Type -> Type) :: (Type -> Type) -> (Type -> Type) -> Type ghci> :kind (:~:) @(Type -> Type) [] (:~:) @(Type -> Type) [] :: (Type -> Type) -> Type ghci> :kind (:~:) @(Type -> Type) [] Maybe (:~:) @(Type -> Type) [] Maybe :: Type }}} Working like {{{ ghci> type Same k (a::k) (b::k) = a :~: b ghci> :kind Same Same :: forall k -> k -> k -> * }}} {{{ ghci> :kind Same (Type -> Type) Same (Type -> Type) :: (Type -> Type) -> (Type -> Type) -> * ghci> :kind Same (Type -> Type) [] Same (Type -> Type) [] :: (Type -> Type) -> * ghci> :kind Same (Type -> Type) [] Maybe Same (Type -> Type) [] Maybe :: * }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders
by GHC 16 Jan '19

16 Jan '19

#15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies, | CUSKs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program and GHCi session which uses it: {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Foo where import Data.Kind type family T1 (x :: Type) (y :: a) :: Type where {} type family T2 x (y :: a) :: Type where {} }}} {{{ $ ghc2/inplace/bin/ghc-stage2 --interactive Foo.hs -fprint-explicit- foralls GHCi, version 8.7.20180831: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, one module loaded. λ> :kind T1 T1 :: forall a. * -> a -> * λ> :kind T2 T2 :: forall {k} {a}. k -> a -> * }}} Note that `T1` quantifies `a` visibly whereas `T2` does not. I find this somewhat surprising, since both `T1` and `T2` explicitly mention `a` in their respective definitions. The only difference between the two is that `T1` has a CUSK while `T2` does not. This isn't of much importance at the moment, but it will be once visible kind application lands, as this will prevent anyone from instantiating the `a` in `T2` using a kind application. It's unclear to me whether this is intended behavior or not. I suppose there might be an unwritten rule that you can't use visible kind application on anything that doesn't have a CUSK, but if this really is the case, we should be upfront about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15801: "ASSERT failed!" with visible kind applications
by GHC 16 Jan '19

16 Jan '19

#15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry for the workload mnguyen. This gives a very short error (using diff for visible kind application: https://phabricator.haskell.org/D5229) {{{#!hs {-# Language CPP #-} {-# Language QuantifiedConstraints #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language TypeOperators #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language TypeSynonymInstances #-} {-# Language FlexibleInstances #-} {-# Language GADTs #-} {-# Language UndecidableInstances #-} {-# Language MultiParamTypeClasses #-} {-# Language FlexibleContexts #-} import Data.Coerce import Data.Kind type Cat ob = ob -> ob -> Type type Obj = Type class Coercible (op_a --> b) (b <-- op_a) => (op_a -#- b) instance Coercible (op_a --> b) (b <-- op_a) => (op_a -#- b) class (forall (op_a :: obj) (b :: obj). op_a -#- b) => OpOpNoOp obj instance (forall (op_a :: obj) (b :: obj). op_a -#- b) => OpOpNoOp obj class Ríki (obj :: Obj) where type (-->) :: obj -> obj -> Type ið :: a --> (a::obj) class OpOpNoOp obj => OpRíki (obj :: Obj) where type (<--) :: obj -> obj -> Type data Op a = Op a type family UnOp op where UnOp ('Op obj) = obj newtype Y :: Cat (Op a) where Y :: (UnOp b --> UnOp a) -> Y a b instance Ríki Type where type (-->) = (->) ið x = x instance OpRíki (Op Type) where type (<--) @(Op Type) = Y @Type }}} {{{ $ ghci -ignore-dot-ghci 577.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 577.hs, interpreted ) *** Exception: ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1285 > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15801> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15795: Core lint error with visible kind patterns
by GHC 16 Jan '19

16 Jan '19

#15795: Core lint error with visible kind patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Finally managed to trigger a core lint error with #12045 {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language TypeOperators #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind type Cat ob = ob -> ob -> Type data (×) :: forall (cat1 :: Cat ob1) (cat2 :: Cat ob2). Cat (ob1, ob2) where Prod :: forall ob1 ob2 cat1 cat2 a1 b1 a2 b2 u. cat1 a1 b1 -> cat2 a2 b2 -> (×) @u '(a1, a2) '(b1, b2) }}} log attached from running `ghci -ignore-dot-ghci <file>.hs` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15795> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10