October 2016 - ghc-tickets

[GHC] #12679: Permit abstract data types in signatures that don't have kind *
by GHC 05 Jan '17

05 Jan '17

#12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | 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: -------------------------------------+------------------------------------- Here is a fascinating program that I would like to write, but cannot with Backpack today: {{{ unit p where signature Key where import GHC.Exts (Constraint) data Key k :: Constraint instance Key Bool signature Map where import Key data Map k a empty :: Map k a insert :: Key k => k -> a -> Map k a -> Map k a lookup :: Key k => k -> Map k a -> Maybe a signature Keys where import Map module M where import Map import Key x = insert True "foo" empty }}} `data Key k :: Constraint` is implementable, because we can implement abstract data types using type synonyms in Backpack, and synonyms can have more kinds than just `*`. However, GHC chokes on this declaration, because it thinks that data types always have to have kind `*`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10680: Make Backpack order-independent (again)
by GHC 05 Jan '17

05 Jan '17

#10680: Make Backpack order-independent (again) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.11 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When we moved to the new `bkp` file format, we also went back to the a format which is order-dependent: that is to say, the order in which you put the declarations matters. So if you write: {{{ unit p where module A where import B module B where ... }}} this fails to type-check, GHC complaining that `B` is not in scope. I did this, in part because it's what the Backpack paper described, and because it was "simpler" to implement. I think we should move back to an order-independent scheme, for the following reasons: 1. Haskell users are used to not needing pay particularly close attention to the ordering of their modules, and forcing people to linearize their module descriptions would be spectacularly disruptive with large amounts of modules. So un-ordered modules are "more natural. 2. Order-independence imposes some constraints on how expressive programs are (with order-dependent Backpack, you can do some pretty tricky things by ordering things certain ways); this could simplify some aspects of compiler implementation and make Backpack easier to explain. 3. A particular case of (2): it seems a lot simpler UX-wise to let a user assume that if you import a module `M` in a unit, it doesn't matter where you import it: you always get the same set of identifiers brought into scope. Thus, the incremental results of signatures should not be visible, c.f. #10679 The main idea is that only the surface-syntax is un-ordered: the internal representation of units is a DAG which we work out in an elaboration phase, not altogether unsimilar from what `GhcMake` computes. Here are the details: **The intermediate representation.** We translate into an intermediate representation which consists of a directed graph between modules, signatures and includes. Edges in the graph indicate a "depends on" relation: 1. `include p` depends on `include q` if, for some module name `H`, `p` requires `H` and `q` provides `H`. 2. A module/signature `M` depends on `include p` if `M` imports a module provided or required by `p`. 3. A module/signature `M` depends on a module/signature `S` if `M` imports `S`. 4. An `include p` depends on a module `M` if `p` requires a module named `M`. (This rule is included for completeness; we are going to disallow it shortly.) We impose one restriction: a signature cannot depend on a home module. See below for how to eliminate this restriction. Rule (2) is worth remarking upon: if a module imports a signature, it depends-on every `include` which requires that signature, as well as the relevant home signature. This could easily result in a cycle; see (2) for how to break these cycles. The consequence of this, however, is that we can factor the graph to introduce the node for the "merge of signatures", which depends on each signature and include which requires it; we can use this opportunity to build and write out the merged interface file for the unit. **Elaboration.** Take a Backpack file, construct this graph, and topsort it into a DAG of SCCs. SCCs with a single node are compileable as before. SCCs with multiple nodes will have to be managed with some mutual recursion mechanism; see refinements for more thoughts on this. **Refinements:** 1. **Can a signature depend on a (home) module?** Imports of this kind require a retypecheck loop. Consider this situation: {{{ unit p where signature H where data T module M where import H data S = S T unit q where include p module Q where import M signature H where import Q data T = T S }}} Here, signature H in q depends on Q. When we typecheck `Q`, we bring `M.S` into the type environment with a `TyThing` that describes the constructor as accepting an abstract type `T`. However, when we subsequently typecheck the local signature `H`, we must refine all `TyThing`s of `T` with the true description (e.g. constructor information). So you'll need to retypecheck `Q` (and `M`) in order to make sure the `TyThing` is correct. 2. **Can an include depend on a (home) module?** If the module has no (transitive) dependency on signatures, this is fine. However, it's easy to have a circular dependency. Consider: {{{ unit p where signature A signature B module M unit q where include p module B where import A ... }}} `B` depends on `p` for `p/A.hsig`; however, `p` depends on `B` because this module is filling a requirement. Fortunately, we can untangle this knot without any mutual recursion nonsense (and the attendant efficiency loss): `A` is just an export list, we can compute it from the abstractly type-checked version of `p` without instantiating `B`. 3. **Can we deal with include-include dependency cycles?** Yes! Just use the Backpack paper's strategy for creating a recursive unit key and compile the two packages `hs-boot` style. But I'm not planning on implementing this yet. 4. **Can we deal with signature-signature dependency cycles?** Ordered Backpack would have supported this: {{{ unit a-sig where signature A where data T unit ab-sig where include a-sig signature B where import A data S = S T signature A where import B data T = T S }}} In our model, `ab-sig` has a cycle. However, I believe any such cycle can be broken by creating sufficiently many units: {{{ unit a-sig where signature B where data T signature A where data S = S T unit b-sig where signature A where data S signature B where data T = T S unit ab-sig where include a-sig include b-sig }}} In principle, GHC could automatically break import cycles by replacing an import with an import of a reduced signature that simply has abstract type definitions. (I'm not sure this is possible for all language features.) This technique would also work for normal modules, assuming that every function is explicitly annotated with a type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12189: sigof01m broken after D2030
by GHC 05 Jan '17

05 Jan '17

#12189: sigof01m broken after D2030 -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: sigof01m | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With [https://phabricator.haskell.org/D2030 D2030] I've changed the implementation of `Ord UnitId` to go from being `Unique` defined to being lexicographic. That somehow broke `sigof01m`. {{{ <ezyang> I think I know what the problem is (ghc --make isn't specifying a dependency from B to A) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10838: hsig files don't have good enough error checking for wired-in types
by GHC 05 Jan '17

05 Jan '17

#10838: hsig files don't have good enough error checking for wired-in types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If I have the signature: {{{ {-# LANGUAGE NoImplicitPrelude #-} module MyPrelude where data Int a }}} And I compile it with `ghc MyPrelude.hsig -sig-of "MyPrelude is base:Prelude"` this won't actually give an error, despite `Int` having the wrong kind. The bug seems to be because `Int` is wired in and this case is not handled. Filing this so I don't forget to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11564: Possible overzealous unfolding
by GHC 04 Jan '17

04 Jan '17

#11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I was investigating why (>>=) in the Haxl monad is being inlined more than I would expect, and I ran into something I don't fully understand, and looks dubious. Start from this standalone example: {{{ {-# LANGUAGE ScopedTypeVariables, ExistentialQuantification #-} module Haxl where import Data.IORef import Control.Exception newtype GenHaxl u a = GenHaxl { unHaxl :: Int -> IORef () -> IO (Result u a) } data Result u a = Done a | Throw SomeException | Blocked (Cont u a) data Cont u a = forall b. Cont u b :>>= (b -> GenHaxl u a) | forall b. (b -> a) :<$> (Cont u b) instance Monad (GenHaxl u) where return a = GenHaxl $ \_env _ref -> return (Done a) GenHaxl m >>= k = GenHaxl $ \env ref -> do e <- m env ref case e of Done a -> unHaxl (k a) env ref Throw e -> return (Throw e) Blocked cont -> return (Blocked (cont :>>= k)) instance Functor (GenHaxl u) instance Applicative (GenHaxl u) }}} (it could be simplified further, but I've intentionally used the exact definition of `>>=` that is used in Haxl to be sure I'm not investigating the wrong thing) Compile like this: {{{ ghc -O -c Haxl.hs }}} and look at the .hi file: {{{ ghc --show-iface Haxl.hi }}} see this: {{{ ea159c3b107c307a4e76cd310efcc8bc $fMonadGenHaxl2 :: GenHaxl u a -> (a -> GenHaxl u b) -> Int -> IORef () -> State# RealWorld -> (# State# RealWorld, Result u b #) {- Arity: 5, HasNoCafRefs, Strictness: <C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))><L,U><L,U><L,U><S,U>, Unfolding: InlineRule (5, True, False) (\ @ u @ a @ b (ds :: GenHaxl u a) (k :: a -> GenHaxl u b) (env :: Int) (ref :: IORef ()) (s :: State# RealWorld)[OneShot] -> case (ds `cast` (N:GenHaxl[0] <u>_P <a>_R) env ref) `cast` (N:IO[0] <Result u a>_R) s of ds1 { (#,#) ipv ipv1 -> case ipv1 of wild { Done a1 -> ((k a1) `cast` (N:GenHaxl[0] <u>_P <b>_R) env ref) `cast` (N:IO[0] <Result u b>_R) ipv Throw e -> (# ipv, Throw @ u @ b e #) Blocked cont -> (# ipv, Blocked @ u @ b (:>>= @ u @ b @ a cont k) #) } }) -} }}} That right there is the definition of `>>=`. Note that it has an `InlineRule`, which means that it will be unconditionally unfolded pretty much everywhere. I don't think this is right - there's no benefit to be had in inlining it unconditionally. I delved in a bit more, and it seems this unfolding arises during worker- wrapper. Before WW we have {{{ a_sVM [LclId, Arity=5, Str=DmdType <C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))><L,U><L,U><L,U><S,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 60 0 0 0] 94 60}] a_sVM = \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Dmd=<C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))>] k_aEC env_aED ref_aEE s_aVC [Dmd=<S,U>, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead, Dmd=<L,A>] { (# ipv_aVF [Dmd=<S,U>], ipv1_aVG [Dmd=<S,1*U>] #) -> case ipv1_aVG of _ [Occ=Dead, Dmd=<L,A>] { Done a_aEG -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } } }}} and after WW we have {{{ a_sVM [LclId, Arity=5, Str=DmdType <C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))><L,U><L,U><L,U><S,U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=5,unsat_ok=True,boring_ok=False) Tmpl= \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Occ=Once] k_aEC [Occ=Once*] env_aED ref_aEE s_aVC [Occ=Once, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead] { (# ipv_aVF [Occ=Once*], ipv1_aVG [Occ=Once!] #) -> case ipv1_aVG of _ [Occ=Dead] { Done a_aEG [Occ=Once] -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH [Occ=Once] -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI [Occ=Once] -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } }}] a_sVM = \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Dmd=<C(C(C(S(SS)))),1*C1(C1(C1(U(U,1*U))))>] k_aEC env_aED ref_aEE s_aVC [Dmd=<S,U>, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead, Dmd=<L,A>] { (# ipv_aVF [Dmd=<S,U>], ipv1_aVG [Dmd=<S,1*U>] #) -> case ipv1_aVG of _ [Occ=Dead, Dmd=<L,A>] { Done a_aEG -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } } }}} For some unknown reason, this binding has acquired an always-on unfolding. There's no wrapper, we're just unfolding the whole thing. Simon, can you shed any light here? I would like to tune unfolding sizes to reduce code bloat in our codebase, but with this unfolding being unconditional it doesn't work to use `-funfolding-use-threshold`, I can only use `NOINLINE` but that's too blunt. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures
by GHC 03 Jan '17

03 Jan '17

#12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 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: -------------------------------------+------------------------------------- This code compiles without issue on GHC 8.0.1 and earlier, but not with GHC 8.0.2 or HEAD. This was adapted from the [https://github.com/kazu- yamamoto/logger/blob/master/monad-logger/Control/Monad/Logger.hs monad- logger] library (which fails to build with GHC 8.0.2 and HEAD due to the same issue): {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE GADTs #-} module MonadLogger where import Control.Monad.IO.Class import qualified Control.Monad.Trans.Class as Trans import Control.Monad.Trans.Identity data Loc data LogSource data LogLevel data LogStr class ToLogStr msg class Monad m => MonadLogger m class (MonadLogger m, MonadIO m) => MonadLoggerIO m where askLoggerIO :: m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) default askLoggerIO :: (Trans.MonadTrans t, MonadLogger (t m), MonadIO (t m)) => t m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) askLoggerIO = Trans.lift askLoggerIO instance MonadLogger m => MonadLogger (IdentityT m) instance MonadLoggerIO m => MonadLoggerIO (IdentityT m) }}} On GHC HEAD, this fails with: {{{ [1 of 1] Compiling MonadLogger ( MonadLogger.hs, interpreted ) MonadLogger.hs:23:10: error: • Couldn't match type ‘m’ with ‘IdentityT m’ ‘m’ is a rigid type variable bound by the instance declaration at MonadLogger.hs:23:10-55 Expected type: IdentityT m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) Actual type: IdentityT (IdentityT m) (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) • In the expression: MonadLogger.$dmaskLoggerIO @IdentityT m In an equation for ‘askLoggerIO’: askLoggerIO = MonadLogger.$dmaskLoggerIO @IdentityT m In the instance declaration for ‘MonadLoggerIO (IdentityT m)’ • Relevant bindings include askLoggerIO :: IdentityT m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) (bound at MonadLogger.hs:23:10) }}} This stopped typechecking after d2958bd08a049b61941f078e51809c7e63bc3354 (i.e, #12220). As a workaround, you can change the default signature to: {{{#!hs default askLoggerIO :: (Trans.MonadTrans t, MonadLoggerIO n, t n ~ m) => t n (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) }}} And it'll work. Any thoughts on this, Simon? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects
by GHC 03 Jan '17

03 Jan '17

#12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | 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 7.10 rejects this datatype: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) }}} {{{ $ /opt/ghc/7.10.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:1: Kind variable also used as type variable: ‘a’ In the data type declaration for ‘T’ }}} But GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`: {{{#!hs data T a (a :: a) }}} Results in this error: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:8: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:8 Bug.hs:5:11 Bug.hs:5:16: error: Type variable ‘a’ used in a kind. Did you mean to use TypeInType? the data type declaration for ‘T’ }}} But with this modification: {{{#!hs data T (a :: a) a }}} You won't get an error message about `a` being used as both a kind and type: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:9: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:9 Bug.hs:5:17 }}} To make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) class C x instance C (T (a :: a)) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:16: error: Variable ‘a’ used as both a kind and a type Did you intend to use TypeInType? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ...
by GHC 01 Jan '17

01 Jan '17

#12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12001 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Made this its own ticket, rather than using #12001. Are these worth adding? {{{#!hs pattern Cont :: ((a -> r) -> r) -> Cont r a pattern Cont a <- (runCont -> a) where Cont a = cont a pattern Writer :: (a, w) -> Writer w a pattern Writer a <- (runWriter -> a) where Writer a = WriterT (Identity a) pattern Reader :: (r -> a) -> Reader r a pattern Reader a <- (runReader -> a) where Reader a = reader a pattern State :: (s -> (a, s)) -> State s a pattern State a <- (runState -> a) where State a = state a }}} The mtl API was changed way back when (before advent of pattern synonyms) which caused some [http://stackoverflow.com/questions/14157090/has-the- control-monad-state-api-changed-recently confusion], [http://learnyouahaskell.com/for-a-few-monads-more LYAH] still uses `Writer`, `State` in their examples. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12241: Surprising constructor accumulation
by GHC 30 Dec '16

30 Dec '16

#12241: Surprising constructor accumulation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `containers` version 0.5.7.1 (and a few earlier versions) uses the following implementation of `fromList` by Ross Paterson: {{{#!hs fromList :: [a] -> Seq a fromList = Seq . mkTree 1 . map_elem where {-# SPECIALIZE mkTree :: Int -> [Elem a] -> FingerTree (Elem a) #-} {-# SPECIALIZE mkTree :: Int -> [Node a] -> FingerTree (Node a) #-} mkTree :: (Sized a) => Int -> [a] -> FingerTree a mkTree !_ [] = EmptyT mkTree _ [x1] = Single x1 mkTree s [x1, x2] = Deep (2*s) (One x1) EmptyT (One x2) mkTree s [x1, x2, x3] = Deep (3*s) (One x1) EmptyT (Two x2 x3) mkTree s (x1:x2:x3:x4:xs) = case getNodes (3*s) x4 xs of (ns, sf) -> case mkTree (3*s) ns of !m -> Deep (3*size x1 + size m + size sf) (Three x1 x2 x3) m sf getNodes :: Int -> a -> [a] -> ([Node a], Digit a) getNodes !_ x1 [] = ([], One x1) getNodes _ x1 [x2] = ([], Two x1 x2) getNodes _ x1 [x2, x3] = ([], Three x1 x2 x3) getNodes s x1 (x2:x3:x4:xs) = (Node3 s x1 x2 x3:ns, d) where (ns, d) = getNodes s x4 xs map_elem :: [a] -> [Elem a] #if __GLASGOW_HASKELL__ >= 708 map_elem xs = coerce xs #else map_elem xs = Data.List.map Elem xs #endif {-# INLINE map_elem #-} }}} This uses one lazy list per "level" in the tree being constructed. I believe Paterson (and pretty much everyone else) expected that there would be `O(log n)` pair constructors and conses live at any given time. Wadler's technique in [http://homepages.inf.ed.ac.uk/wadler/papers/leak/leak.ps.gz Fixing some space leaks with a garbage collector], which the GHC commentary indicates is used in GHC, should clean up the pairs in `getNodes`'s `d` thunks as they reach WHNF. Lennart Spitzner dug into the unimpressive performance of the above code and using {{{#!hs main = evaluate $ S.fromList [(0::Int)..999999] }}} produced [http://heap.ezyang.com/view/72d4d1eb879a2085ffd49d270b03c7a037b4d5c2 this heap profile]. If I'm reading it right, this suggests that there are lots of `(,)` and also `(:)` constructors live, more `O(n)` than `O(log n)`. I had previously found that I could improve performance by building the intermediate lists strictly, but that violates the generational hypothesis and leads to a slow-down for very large arguments ([http://heap.ezyang.com/view/2e80598f73d9281f5eadfeb041f5b9aef6e448b0 Spitzner's heap profile]). Spitzner was able to come up with a very clever (but much trickier) implementation that skirted all these problems ([http://heap.ezyang.com/view/7f1994c0417931360fe7c41bd995c37ebc3fd6c5 profile]) and avoids ever allocating the troublesome pairs. So the problem is thoroughly bypassed for `containers`, but it seems like something is not quite right here, and it might bear looking into. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11216: RebindableSyntax with pattern guards needs `fail`
by GHC 26 Dec '16

26 Dec '16

#11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE RebindableSyntax #-} module Bug where foo :: (a, b) -> () foo x | (_,_) <- x = () }}} I get {{{ Bug.hs:6:9: error: Not in scope: ‘fail’ }}} Yet even if I bring `fail` into scope, it's not mentioned in the Core produced by my program. And it really shouldn't: there's not a monad in sight! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8