- ghc-tickets - Haskell.org

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 22 Oct '15

22 Oct '15

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): I am so curious that I want to ask for the second case "You have an instance of Monad, but not Applicative" why cann't we add default implementation to Applicative typeclass? {{{ class Functor f => Applicative f where pure :: a -> f a default pure :: Monad f => a -> f a pure = return (<*>) :: f (a -> b) -> f a -> f b default (<*>) :: Monad f => f (a -> b) -> f a -> f b (<*>) f a = ap }}} Replying to [comment:14 Austin Seipp <austin@…>]: > In [changeset:75a9664af1c4e6f87794b49a215adb235b20696d/ghc]: > {{{ > #!CommitTicketReference repository="ghc" revision="75a9664af1c4e6f87794b49a215adb235b20696d" > Implement the AMP warning (#8004) > > This patch implements a warning when definitions conflict with the > Applicative-Monad Proposal (AMP), described in #8004. Namely, this will > cause a warning iff: > > * You have an instance of Monad, but not Applicative > * You have an instance of MonadPlus, but not Alternative > * You locally defined a function named join, <*>, or pure. > > In GHC 7.10, these warnings will actually be enforced with superclass > constraints through changes in base, so programs will fail to compile > then. > > This warning is enabled by default. Unfortunately, not all of > our upstream libraries have accepted the appropriate patches. So we > temporarily fix ./validate by ignoring the AMP warning. > > Dan Rosén made an initial implementation of this change, and the > remaining work was finished off by David Luposchainsky. I finally made > some minor refactorings. > > Authored-by: Dan Rosén <danr(a)chalmers.se> > Authored-by: David Luposchainsky <dluposchainsky(a)gmail.com> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5646: Initialise tuples using pragmas
by GHC 22 Oct '15

22 Oct '15

#5646: Initialise tuples using pragmas -------------------------------------+------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Data Parallel | Version: 7.3 Haskell | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => low Comment: I suspect this bug now refers to the FIXME in `compiler/vectorise/Vectorise/Builtins/Initialise.hs:initBuiltinVars`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5646#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5429: Docase notation as GHC extension
by GHC 22 Oct '15

22 Oct '15

#5429: Docase notation as GHC extension -------------------------------------+------------------------------------- Reporter: tomasp | Owner: tomasp Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: wontfix | Keywords: monad, | syntactic sugar, mzip, | comprehensions 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 bgamari): * status: new => closed * resolution: => wontfix Old description: > Many monads provide additional combinators for ''parallel composition'', > ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper > (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with > these 3 additional combinators a '''joinad'''. > > The monads that implement (some of) these three operations include: > > * '''Par monad''' for parallel programming implements ''parallel > composition'' (run two computations in parallel) and ''aliasing'' (start > computation and access the result in multiple other computations) and can > be extended to support (non-deterministic) ''choice'' > * '''Parsers''' can implement ''parallel composition'' as an > intersection of languages (parse the same input using multiple parsers), > which is useful for encoding validation rules and ''choice'' (use the > result of a first parser that succeeds). > * '''Other monads''' that can be considered include the `Orc` monad > (for concurrent orchestration) and the encoding of CHP (Communicating > Haskell Processes). > > The proposal is to implement the a GHC extension that allows the `docase` > notation for working with ''joinads''. Using the `Par` monad as an > example, the following snippet implements a function `all` which tests > whether a predicate holds for all leaves of a tree: > > {{{ > all :: (a -> Bool) -> Tree a -> Par Bool > > all p (Leaf v) = return (p v) > all p (Node left right) = > docase all p left, all p right of > False, ? -> return False > ?, False -> return False > allL, allR -> return (allL && allR) > }}} > > The left and right sub-trees are processed in parallel (using ''parllel > composition''). The special pattern `?` denotes that the corresponding > computation does not have to complete in order for the clause to match. > This means that the first two clauses implement short-circuiting behavior > (and can match even if the other branch is still being processed). > > The operations used by the desugaring are expected to have the following > types: > > * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by > the recent patch that re-implements ''monad comprehensions'', so we can > reuse it. > * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as > `mplus` from `MonadPlus`, but we require an operation that is left- > biased. One possible option is to add `MonadOr` type class as suggested > in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. > * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation > and returns a handle for accessing the result. It has been used e.g. by > the authors of the `Orc` monad. For many simpler monads, this can be > implemented as monadic `return`. > > ==Feedback== > > I would appreciate any feedback from GHC users and developers! In > particular, here are some general, as well as more specific questions > that I've heard in the past: > > * What existing monads can implement the interface? (I believe there are > quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to > know about more.) > > * What to do about monads that implement only some operations? > Currently, the `malias` operation has default implementation. If a > `docase` notation has just a single clause, then `morelse` is not > required. If it has multiple clauses, each having just a single ''binding > pattern'' (non `?`) then `mzip` is not required. > > * The laws - the paper includes detailed discussion about laws (e.g. why > `mzip` should be symmetric and why `morelse` should have left-biase). > Does the community agree with the laws, or do you suggest some changes? > > * Syntax seems to be a tricky question - the notation intentionally > resembles `case`, but it takes a list of arguments (of type `m a1`, ..., > `m an`), so it is not using ''tuple syntax''. Is there any better > alternative? > > * Correspondence with ''monad comprehensions'' - the `docase` notation > can express parallel composition in a similar way as ''monad > comprehensions''. I think this parity is a good thing. However, it allows > more expressivity in one direction (by adding choice) and less in another > (no group/order by comprehensions). Do you think this is a good ballance? New description: Many monads provide additional combinators for ''parallel composition'', ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with these 3 additional combinators a '''joinad'''. The monads that implement (some of) these three operations include: * '''Par monad''' for parallel programming implements ''parallel composition'' (run two computations in parallel) and ''aliasing'' (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) ''choice'' * '''Parsers''' can implement ''parallel composition'' as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and ''choice'' (use the result of a first parser that succeeds). * '''Other monads''' that can be considered include the `Orc` monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes). The proposal is to implement the a GHC extension that allows the `docase` notation for working with ''joinads''. Using the `Par` monad as an example, the following snippet implements a function `all` which tests whether a predicate holds for all leaves of a tree: {{{ all :: (a -> Bool) -> Tree a -> Par Bool all p (Leaf v) = return (p v) all p (Node left right) = docase all p left, all p right of False, ? -> return False ?, False -> return False allL, allR -> return (allL && allR) }}} The left and right sub-trees are processed in parallel (using ''parllel composition''). The special pattern `?` denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed). The operations used by the desugaring are expected to have the following types: * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by the recent patch that re-implements ''monad comprehensions'', so we can reuse it. * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as `mplus` from `MonadPlus`, but we require an operation that is left-biased. One possible option is to add `MonadOr` type class as suggested in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the `Orc` monad. For many simpler monads, this can be implemented as monadic `return`. == Feedback == I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past: * What existing monads can implement the interface? (I believe there are quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to know about more.) * What to do about monads that implement only some operations? Currently, the `malias` operation has default implementation. If a `docase` notation has just a single clause, then `morelse` is not required. If it has multiple clauses, each having just a single ''binding pattern'' (non `?`) then `mzip` is not required. * The laws - the paper includes detailed discussion about laws (e.g. why `mzip` should be symmetric and why `morelse` should have left-biase). Does the community agree with the laws, or do you suggest some changes? * Syntax seems to be a tricky question - the notation intentionally resembles `case`, but it takes a list of arguments (of type `m a1`, ..., `m an`), so it is not using ''tuple syntax''. Is there any better alternative? * Correspondence with ''monad comprehensions'' - the `docase` notation can express parallel composition in a similar way as ''monad comprehensions''. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good balance? -- Comment: tomasp, I'm going to close this due to inactivity but feel free to reopen with a Phabricator Diff if you still want to see this happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5429#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5429: Docase notation as GHC extension
by GHC 22 Oct '15

22 Oct '15

#5429: Docase notation as GHC extension -------------------------------------+------------------------------------- Reporter: tomasp | Owner: tomasp Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: monad, | syntactic sugar, mzip, | comprehensions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Many monads provide additional combinators for ''parallel composition'', > ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper > (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with > these 3 additional combinators a '''joinad'''. > > The monads that implement (some of) these three operations include: > > * '''Par monad''' for parallel programming implements ''parallel > composition'' (run two computations in parallel) and ''aliasing'' (start > computation and access the result in multiple other computations) and can > be extended to support (non-deterministic) ''choice'' > * '''Parsers''' can implement ''parallel composition'' as an > intersection of languages (parse the same input using multiple parsers), > which is useful for encoding validation rules and ''choice'' (use the > result of a first parser that succeeds). > * '''Other monads''' that can be considered include the `Orc` monad > (for concurrent orchestration) and the encoding of CHP (Communicating > Haskell Processes). > > The proposal is to implement the a GHC extension that allows the `docase` > notation for working with ''joinads''. Using the `Par` monad as an > example, the following snippet implements a function `all` which tests > whether a predicate holds for all leaves of a tree: > > {{{ > all :: (a -> Bool) -> Tree a -> Par Bool > > all p (Leaf v) = return (p v) > all p (Node left right) = > docase all p left, all p right of > False, ? -> return False > ?, False -> return False > allL, allR -> return (allL && allR) > }}} > > The left and right sub-trees are processed in parallel (using ''parllel > composition''). The special pattern `?` denotes that the corresponding > computation does not have to complete in order for the clause to match. > This means that the first two clauses implement short-circuiting behavior > (and can match even if the other branch is still being processed). > > The operations used by the desugaring are expected to have the following > types: > > * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by > the recent patch that re-implements ''monad comprehensions'', so we can > reuse it. > * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as > `mplus` from `MonadPlus`, but we require an operation that is left- > biased. One possible option is to add `MonadOr` type class as suggested > in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. > * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation > and returns a handle for accessing the result. It has been used e.g. by > the authors of the `Orc` monad. For many simpler monads, this can be > implemented as monadic `return`. > > ===Feedback=== > I would appreciate any feedback from GHC users and developers! In > particular, here are some general, as well as more specific questions > that I've heard in the past: > > * What existing monads can implement the interface? (I believe there are > quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to > know about more.) > > * What to do about monads that implement only some operations? > Currently, the `malias` operation has default implementation. If a > `docase` notation has just a single clause, then `morelse` is not > required. If it has multiple clauses, each having just a single ''binding > pattern'' (non `?`) then `mzip` is not required. > > * The laws - the paper includes detailed discussion about laws (e.g. why > `mzip` should be symmetric and why `morelse` should have left-biase). > Does the community agree with the laws, or do you suggest some changes? > > * Syntax seems to be a tricky question - the notation intentionally > resembles `case`, but it takes a list of arguments (of type `m a1`, ..., > `m an`), so it is not using ''tuple syntax''. Is there any better > alternative? > > * Correspondence with ''monad comprehensions'' - the `docase` notation > can express parallel composition in a similar way as ''monad > comprehensions''. I think this parity is a good thing. However, it allows > more expressivity in one direction (by adding choice) and less in another > (no group/order by comprehensions). Do you think this is a good ballance? New description: Many monads provide additional combinators for ''parallel composition'', ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with these 3 additional combinators a '''joinad'''. The monads that implement (some of) these three operations include: * '''Par monad''' for parallel programming implements ''parallel composition'' (run two computations in parallel) and ''aliasing'' (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) ''choice'' * '''Parsers''' can implement ''parallel composition'' as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and ''choice'' (use the result of a first parser that succeeds). * '''Other monads''' that can be considered include the `Orc` monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes). The proposal is to implement the a GHC extension that allows the `docase` notation for working with ''joinads''. Using the `Par` monad as an example, the following snippet implements a function `all` which tests whether a predicate holds for all leaves of a tree: {{{ all :: (a -> Bool) -> Tree a -> Par Bool all p (Leaf v) = return (p v) all p (Node left right) = docase all p left, all p right of False, ? -> return False ?, False -> return False allL, allR -> return (allL && allR) }}} The left and right sub-trees are processed in parallel (using ''parllel composition''). The special pattern `?` denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed). The operations used by the desugaring are expected to have the following types: * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by the recent patch that re-implements ''monad comprehensions'', so we can reuse it. * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as `mplus` from `MonadPlus`, but we require an operation that is left-biased. One possible option is to add `MonadOr` type class as suggested in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the `Orc` monad. For many simpler monads, this can be implemented as monadic `return`. ==Feedback== I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past: * What existing monads can implement the interface? (I believe there are quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to know about more.) * What to do about monads that implement only some operations? Currently, the `malias` operation has default implementation. If a `docase` notation has just a single clause, then `morelse` is not required. If it has multiple clauses, each having just a single ''binding pattern'' (non `?`) then `mzip` is not required. * The laws - the paper includes detailed discussion about laws (e.g. why `mzip` should be symmetric and why `morelse` should have left-biase). Does the community agree with the laws, or do you suggest some changes? * Syntax seems to be a tricky question - the notation intentionally resembles `case`, but it takes a list of arguments (of type `m a1`, ..., `m an`), so it is not using ''tuple syntax''. Is there any better alternative? * Correspondence with ''monad comprehensions'' - the `docase` notation can express parallel composition in a similar way as ''monad comprehensions''. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good ballance? -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5429#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4295: Review higher-rank and impredicative types
by GHC 22 Oct '15

22 Oct '15

#4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.12.3 checker) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Simon, did this ever happen? It looks like most of the tests you list are okay, ||= test =||= status =|| || tc150 || ok || || tc194 || ok || || tcfail198 || ok || || tcfail174 || ok || || tcfail165 || ok || || tcfail145 || ok || || tcfail104 || ok || || tc211 || ok || || indexed-types/should_compile/T4120 || ok || || simpl017 || ok || || boxy/Base1 || broken due to #4295 || || boxy/Church1 || broken due to #4295 || || boxy/Church2 || broken due to #1330 || || boxy/PList1 || broken due to #4295 || || boxy/PList2 || broken due to #4295 || || boxy/SystemF || broken due to #4295 || || boxy/boxy || broken due to #4295 || || boxy/Compose || ok || || boxy/T2193 || ok || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4295#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures
by GHC 22 Oct '15

22 Oct '15

#10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures wiki] states that > As a single extra-constraints wildcard is enough to infer any number of constraints, only one is allowed in a type signature and it should come last in the list of constraints. However the following program compiles with GHC 7.10.1 {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} f :: (Eq a, _, _) => a -> a -> Bool f x y = x == y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10428: GHC cannot match representations using Coercible constraint
by GHC 22 Oct '15

22 Oct '15

#10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code compiles in 7.8.4 but fails in 7.10.1: {{{#!hs import Data.Coerce coerceNewtype :: (Coercible (o r) (n m' r)) => [o r] -> [n m' r] coerceNewtype = coerce }}} with the error {{{ Couldn't match representation of type ‘n m' r’ with that of ‘o r’ arising from trying to show that the representations of ‘[o r]’ and ‘[n m' r]’ are the same Relevant role signatures: type role [] representational }}} However, the following compiles: {{{#!hs {-# LANGUAGE TypeFamilies #-} import Data.Coerce coerceNewtype :: (Coercible a b, a ~ (o r), b ~ (n m' r)) => [o r] -> [n m' r] coerceNewtype = coerce }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10428> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10924: Template variable unbound in rewrite rule
by GHC 22 Oct '15

22 Oct '15

#10924: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: singletons, | Operating System: Unknown/Multiple templatehaskell | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- The only ticket I see with this issues that *isn't* resolved in 7.10.2 is #10689. Might be a dup. Compiling with -O1 succeeds, but `ghc -O2` fails: {{{ {-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables, TemplateHaskell, TypeFamilies, UndecidableInstances #-} module Bug where -- needed to use Nat's Num instance for + import qualified GHC.Num as Num import Data.Singletons.Prelude import Data.Singletons.TH import Data.Type.Natural import Data.Typeable -- | Copied from Data.Type.Natural because the data-level version -- is not exported there. (<<=) :: Nat -> Nat -> Bool Z <<= _ = True S _ <<= Z = False S n <<= S m = n <<= m singletons [d| newtype PrimePower = PP (Nat,Nat) deriving (Eq,Show,Typeable) |] singletons [d| ppMul :: PrimePower -> [PrimePower] -> [PrimePower] ppMul x [] = [x] ppMul x@(PP(p,e)) pps@(PP (p',e'):pps') | p == p' = PP(p,e Num.+ e'):pps' | p <<= p' = x:pps | otherwise = (PP(p',e')):ppMul x pps' |] }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Template variable unbound in rewrite rule t_XexU [t_aev4, t_aev5, n0_aeyH, n1_aeyI, n0_aeyV, n1_aeyW, ipv_sfxT, sc_sg53, sc_sg54, sg_sg55, sg_sg56, sc_sg57] [t_XexU, t_XexW, n0_XeBz, n1_XeBB, n0_XeBP, n1_XeBR, ipv_XfAP, sc_Xg80, sc_Xg82, sg_Xg84, sg_Xg86, sc_Xg88] [TYPE Let1627437970XSym7 n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5, TYPE ipv_sfxT, (SPP @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N ((STuple2 @ Nat @ Nat @ '(n0_aeyH, n1_aeyI) @ n0_aeyH @ n1_aeyI @~ <'(n0_aeyH, n1_aeyI)>_N sc_sg53 sc_sg54) `cast` (sg_sg55 :: R:Sing(,)z '(n0_aeyH, n1_aeyI) ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) `cast` (sg_sg56 :: R:SingPrimePowerz ('PP (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)) ~R# Sing (Apply PPSym0 (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))), sc_sg57] [TYPE Let1627437970XSym7 n0_aeyH n1_aeyI n0_XeB0 n1_XeB2 ipv_XfzF (Let1627437970XSym7 n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5) ipv_sfxT, TYPE ipv_XfzF, (SPP @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N ((STuple2 @ Nat @ Nat @ '(n0_aeyH, n1_aeyI) @ n0_aeyH @ n1_aeyI @~ <'(n0_aeyH, n1_aeyI)>_N sc_sg53 sc_sg54) `cast` (Sub (Sym (TFCo:R:Sing(,)z[0] <Nat>_N <Nat>_N)) (Sym (TFCo:R:Apply(,)kTuple2Sym1l0[0] <Nat>_N <Nat>_N <n1_aeyI>_N <n0_aeyH>_N) ; (Apply (Sym (TFCo:R:Apply(->)kTuple2Sym0l0[0] <Nat>_N <Nat>_N <n0_aeyH>_N)) <n1_aeyI>_N)_N) :: R:Sing(,)z (Tuple2Sym2 n0_aeyH n1_aeyI) ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) `cast` (Sub (Sym TFCo:R:SingPrimePowerz[0]) (Sym (TFCo:R:ApplyPrimePower(,)PPSym0l0[0] <(Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI>_N)) :: R:SingPrimePowerz (PPSym1 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) ~R# Sing (Apply PPSym0 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))), ipv_sfxW] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10876: stack overflow regression
by GHC 22 Oct '15

22 Oct '15

#10876: stack overflow regression -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I would like to teach GHC that `<=` is transitive. I tried a module that looks like this: {{{#!hs {-# LANGUAGE GADTs, Rank2Types, TypeOperators #-} import GHC.TypeLits trans :: (a <= b, b <= c) => ((a <= c) => d) -> d trans = undefined }}} In 7.8, this is a type error; in 7.10 the compiler thinks a long time before emitting a stack overflow exception. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10876> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10815: Need more kind inference in associated type instances
by GHC 22 Oct '15

22 Oct '15

#10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} module Bug where import Data.Proxy class kproxy ~ 'KProxy => C (kproxy :: KProxy k) where type F (a :: k) instance C ('KProxy :: KProxy Bool) where type F a = Int }}} I get {{{ Type indexes must match class instance head Found ‘k’ but expected ‘Bool’ In the type instance declaration for ‘F’ In the instance declaration for ‘C (KProxy :: KProxy Bool)’ }}} But the kind of `a` should really be known to be `Bool`. This ticket is broken out from comment:3:ticket:9063, which was evidently not addressed when fixing that ticket. Patch coming soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6