- ghc-tickets - Haskell.org

[GHC] #13995: provide hook for 'setNumCapabilities'
by GHC 19 Jul '17

19 Jul '17

#13995: provide hook for 'setNumCapabilities' -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This request if straight forward: i want to run some code when user call `setNumCapabilities`. I'm making a [https://github.com/winterland1989/stdio/blob/newFD/System/LowResTimer.hs stripped timing wheel implementation], and the problem is obvious: we keep an array of timer managers just like I/O managers, but we have to ask user to call something like `lowResTimerManagerCapabilitiesChanged` so that we can re-allocate new array, which is unreasonable. The same problem exists in some stripped resource pool implementation, so i proposed {{{ -- this is not exported capabilityChangedHook :: IORef (IO ()) capabilityChangedHook = unsafePerformIO $ newIORef (return ()) -- this is exported to user addCapabilityChangedHook :: IO () -> IO () addCapabilityChangedHook f = do atomicModifyIORef' capabilityChangedHook $ \ g -> (g >> f, ()) setNumCapabilities :: ... setNumCapabilities = ... ... -- somewhere inside setNumCapabilities hook <- readIORef capabilityChangedHook hook ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8903: Add dead store elimination
by GHC 18 Jul '17

18 Jul '17

#8903: Add dead store elimination ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- We could use some dead store elimination in the code generator. Here's some Cmm that has redundant stores to the same locations: {{{ // thawArray#: I64[Hp - 168] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I64[Hp - 160] = 16; I64[Hp - 152] = 17; _c2nT::I64 = Hp - 168; call MO_Memcpy(_c2nT::I64 + 24, _s2cx::P64 + 24, 128, 8); // writeArray#: P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)] = _s2cE::P64; I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_DIRTY_info@GOTPCREL]; I8[(_c2nT::I64 + 24) + ((I64[_c2nT::I64 + 8] << 3) + (_s2cy::I64 >> 7))] = 1 :: W8; // unsafeFreeze# I64[_c2nT::I64] = I64[PicBaseReg + stg_MUT_ARR_PTRS_FROZEN0_info@GOTPCREL]; }}} There are three stores to the same location (`I64[_c2nT::I64]`). (There's also one much less obvious double store to another location, which will probably be much harder to address: the store to `P64[(_c2nT::I64 + 24) + (_s2cy::I64 << 3)]` overwrites a word previous written by the `MO_Memcpy`. Getting to that one will be hard as the memcoy callish !MachOp only gets expanded in the backend.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9630: compile-time performance regression (probably due to Generics)
by GHC 18 Jul '17

18 Jul '17

#9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: #9583 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is a continuation of #9583 Compiling latest Cabal from Git's `Language.Haskell.Extension` module shows a significant performance regression with respect to GHC 7.8.3: {{{ $ uname -a Linux duo 3.17.0-031700rc6-generic #201409211935 SMP Sun Sep 21 23:37:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ git describe cabal-install_merged-1912-g7161e4c ######################################################################################## $ /opt/ghc/7.8.3/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 $ /opt/ghc/7.8.3/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 5228751760 bytes, 543 GCs, 34135677/114940864 avg/max bytes residency (14 samples), 273M in use, 0.00 INIT (0.03 elapsed), 4.96 MUT (5.28 elapsed), 3.26 GC (3.47 elapsed) :ghc>> ######################################################################################## $ /opt/ghc/head/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20140923 $ /opt/ghc/head/bin/ghc -Rghc-timing -O -c Language/Haskell/Extension.hs <<ghc: 125917854120 bytes, 3181 GCs, 349136895/833496072 avg/max bytes residency (30 samples), 2096M in use, 0.001 INIT (0.001 elapsed), 133.003 MUT (142.730 elapsed), 73.241 GC (78.234 elapsed) :ghc>> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 66

[GHC] #13310: Cut a new array release
by GHC 18 Jul '17

18 Jul '17

#13310: Cut a new array release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `array` package needs a new release for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds)
by GHC 18 Jul '17

18 Jul '17

#12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11480 #12025 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Glorious Glasgow Haskell Compilation System, version 8.0.1. Code taken from [https://gist.github.com/ekmett/b26363fc0f38777a637d gist] with {{{#!hs fmap :: p a b -> q (f a) (f b) }}} replaced by {{{#!hs fmap :: Dom f a b -> Cod f (f a) (f b) }}} If you enable `DataKinds` and `TypeInType` `:kind` will happily tell you its kind: {{{ ghci> :kind 'Main.Nat 'Main.Nat :: forall j i (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j). (FunctorOf p q f, FunctorOf p q g) => (forall (a :: i). Ob p a => q (f a) (g a)) -> Main.Nat p q f g }}} but if you try `:type Nat` it spits out a long list of unsolved constraints {{{ ghci> :type Nat <interactive>:1:1: error: solveWanteds: too many iterations (limit = 1) Unsolved: WC {wc_simple = [W] $dFunctor_ag3Y :: Main.Functor f_ag3S (CDictCan) [W] $dFunctor_ag4d :: Main.Functor g_ag3T (CDictCan) [D] _ :: Main.Functor s_ag51 (CDictCan) [D] _ :: Main.Functor s_ag5a (CDictCan) [D] _ :: Main.Functor s_ag4W (CDictCan) [D] _ :: Main.Functor s_ag55 (CDictCan) [D] _ :: Category s_ag51 (CDictCan) [D] _ :: Category s_ag5a (CDictCan) [D] _ :: Category s_ag4W (CDictCan) [D] _ :: Category s_ag55 (CDictCan) [W] hole{ag4Y} :: Dom g_ag3T ~ Dom f_ag3S (CNonCanonical) [W] hole{ag53} :: Cod g_ag3T ~ Cod f_ag3S (CNonCanonical) [D] _ :: Dom (Dom f_ag3S) ~ Op (Dom f_ag3S) (CNonCanonical) [D] _ :: Cod (Dom f_ag3S) }}} This seems like #11480. This makes undecidable superclasses a harsh master and raises two questions that I'll bundle together: 1. Why can the `:kind` be inferred but not the `:type`? It works when given extra information: {{{ ghci> :type Nat @_ @_ @(->) @(->) Nat @_ @_ @(->) @(->) :: (Cod g ~ (->), Dom g ~ (->), Cod f ~ (->), Dom f ~ (->), Main.Functor g, Main.Functor f) => (forall a. Vacuous (->) a => f a -> g a) -> Main.Nat (->) (->) f g }}} {{{ ghci> :type Nat @_ @_ @_ @_ @[] @Maybe Nat @_ @_ @_ @_ @[] @Maybe :: (forall a. Vacuous (->) a => [a] -> Maybe a) -> Main.Nat (->) (->) [] Maybe }}} {{{ ghci> :type Nat @_ @_ @_ @_ @[] @Maybe listToMaybe Nat @_ @_ @_ @_ @[] @Maybe listToMaybe :: Main.Nat (->) (->) [] Maybe }}} 2. Why is `j` positioned before `i` (most likely because of `forall a. ...` but I tried tinkering without success? Is there any trick to ordering it as you'd expect `forall i j (p :: Cat i) (q :: Cat j)` or is it not possible per #12025? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13978: oddness surrounding aeson 1.0.2.1 on Debian
by GHC 18 Jul '17

18 Jul '17

#13978: oddness surrounding aeson 1.0.2.1 on Debian -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- per bgamari's request, I am filing this ticket as part of an ongoing plea for help to figure out what is going on. When building aeson 1.0.2.1 on Debian, we get a failure (https://buildd.debian.org/status/fetch.php?pkg=haskell- aeson&arch=amd64&ver=1.0.2.1-2&stamp=1499701762&raw=0) building the testsuite: {{{ [19 of 19] Compiling Data.Aeson.TH ( Data/Aeson/TH.hs, dist- ghc/build/Data/Aeson/TH.p_o ) Preprocessing test suite 'tests' for aeson-1.0.2.1... [ 1 of 13] Compiling Types ( tests/Types.hs, dist- ghc/build/tests/tests-tmp/Types.o ) [ 2 of 13] Compiling Options ( tests/Options.hs, dist- ghc/build/tests/tests-tmp/Options.o ) [ 3 of 13] Compiling Functions ( tests/Functions.hs, dist- ghc/build/tests/tests-tmp/Functions.o ) [ 4 of 13] Compiling Instances ( tests/Instances.hs, dist- ghc/build/tests/tests-tmp/Instances.o ) [ 5 of 13] Compiling Encoders ( tests/Encoders.hs, dist- ghc/build/tests/tests-tmp/Encoders.o ) <command line>: can't load .so/.DLL for: /<<PKGBUILDDIR>>/dist- ghc/build/libHSaeson-1.0.2.1-ATVva2eon9U8IQdb5aU6Rk-ghc8.0.2.so (/<<PKGBUILDDIR>>/dist-ghc/build/libHSaeson-1.0.2.1 -ATVva2eon9U8IQdb5aU6Rk-ghc8.0.2.so: undefined symbol: aesonzm1zi0zi2zi1zmATVva2eon9U8IQdb5aU6Rk_DataziAesonziEncodingziInternal_utcTime1_closure) }}} This symbol is *UND* in the .so, but present in Data/Aeson/Encoding/Internal.o and Data/Aeson/Encoding/Internal.dyn_o . Building the testsuite with -O0 causes it to fail with a different symbol. Building aeson with cabal (modulo having to hand-edit tests/Instances.hs to remove the redundant Tagged instance) results in a successful build of the testsuite. However, if I '''cabal configure --enable-tests --enable- library-profiling''' instead of just '''cabal configure --enable-tests''', then the build fails with {{{ [10 of 20] Compiling Data.Aeson.Internal ( Data/Aeson/Internal.hs, dist/build/Data/Aeson/Internal.o ) [11 of 20] Compiling Data.Aeson.Encoding.Builder ( Data/Aeson/Encoding/Builder.hs, dist/build/Data/Aeson/Encoding/Builder.o ) [12 of 20] Compiling Data.Aeson.Encoding.Internal ( Data/Aeson/Encoding/Internal.hs, dist/build/Data/Aeson/Encoding/Internal.o ) [13 of 20] Compiling Data.Aeson.Encoding ( Data/Aeson/Encoding.hs, dist/build/Data/Aeson/Encoding.o ) [14 of 20] Compiling Data.Aeson.Types.ToJSON ( Data/Aeson/Types/ToJSON.hs, dist/build/Data/Aeson/Types/ToJSON.o ) [15 of 20] Compiling Data.Aeson.Types.Class ( Data/Aeson/Types/Class.hs, dist/build/Data/Aeson/Types/Class.o ) [16 of 20] Compiling Data.Aeson.Types ( Data/Aeson/Types.hs, dist/build/Data/Aeson/Types.o ) [17 of 20] Compiling Data.Aeson.Text ( Data/Aeson/Text.hs, dist/build/Data/Aeson/Text.o ) [18 of 20] Compiling Data.Aeson ( Data/Aeson.hs, dist/build/Data/Aeson.o ) [19 of 20] Compiling Data.Aeson.Encode ( Data/Aeson/Encode.hs, dist/build/Data/Aeson/Encode.o ) [20 of 20] Compiling Data.Aeson.TH ( Data/Aeson/TH.hs, dist/build/Data/Aeson/TH.o ) [ 1 of 20] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, dist/build/Data/Aeson/Types/Internal.p_o ) Data/Aeson/Types/Internal.hs:67:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:76:1: error: Failed to load interface for `Data.HashMap.Strict' Perhaps you haven't installed the profiling libraries for package `unordered-containers-0.2.8.0@unordered- containers-0.2.8.0-9vyhLlLaqmyDfOnbawvdcQ'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:77:1: error: Failed to load interface for `Data.Hashable' Perhaps you haven't installed the profiling libraries for package `hashable-1.2.6.1(a)hashable-1.2.6.1-BImGDn7vOUG6aLx2AeaDao'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:78:1: error: Failed to load interface for `Data.Scientific' Perhaps you haven't installed the profiling libraries for package `scientific-0.3.5.1'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:81:1: error: Failed to load interface for `Data.Text' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2(a)text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:85:1: error: Failed to load interface for `Data.Vector' Perhaps you haven't installed the profiling libraries for package `vector-0.12.0.1'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:87:1: error: Failed to load interface for `Data.HashMap.Strict' Perhaps you haven't installed the profiling libraries for package `unordered-containers-0.2.8.0@unordered- containers-0.2.8.0-9vyhLlLaqmyDfOnbawvdcQ'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:88:1: error: Failed to load interface for `Data.Scientific' Perhaps you haven't installed the profiling libraries for package `scientific-0.3.5.1'? Use -v to see a list of the files searched for. Data/Aeson/Types/Internal.hs:89:1: error: Failed to load interface for `Data.Vector' Perhaps you haven't installed the profiling libraries for package `vector-0.12.0.1'? Use -v to see a list of the files searched for. [ 2 of 20] Compiling Data.Aeson.Types.Generic ( Data/Aeson/Types/Generic.hs, dist/build/Data/Aeson/Types/Generic.p_o ) Data/Aeson/Types/Generic.hs:40:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. [ 3 of 20] Compiling Data.Aeson.Parser.Unescape ( Data/Aeson/Parser/Unescape.hs, dist/build/Data/Aeson/Parser/Unescape.p_o ) Data/Aeson/Parser/Unescape.hs:13:1: error: Failed to load interface for `Data.Text.Array' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2(a)text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:14:1: error: Failed to load interface for `Data.Text.Encoding.Error' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2(a)text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:15:1: error: Failed to load interface for `Data.Text.Internal' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2(a)text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:16:1: error: Failed to load interface for `Data.Text.Internal.Private' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2(a)text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. Data/Aeson/Parser/Unescape.hs:17:1: error: Failed to load interface for `Data.Text.Unsafe' Perhaps you haven't installed the profiling libraries for package `text-1.2.2.2(a)text-1.2.2.2-KC7dWoG09dA1F6jKj5GSqh'? Use -v to see a list of the files searched for. [ 6 of 20] Compiling Data.Aeson.Internal.Time ( Data/Aeson/Internal/Time.hs, dist/build/Data/Aeson/Internal/Time.p_o ) Data/Aeson/Internal/Time.hs:21:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. [ 8 of 20] Compiling Data.Aeson.Internal.Functions ( Data/Aeson/Internal/Functions.hs, dist/build/Data/Aeson/Internal/Functions.p_o ) Data/Aeson/Internal/Functions.hs:18:1: error: Failed to load interface for `Prelude.Compat' Perhaps you haven't installed the profiling libraries for package `base-compat-0.9.3'? Use -v to see a list of the files searched for. Data/Aeson/Internal/Functions.hs:20:1: error: Failed to load interface for `Data.Hashable' Perhaps you haven't installed the profiling libraries for package `hashable-1.2.6.1(a)hashable-1.2.6.1-BImGDn7vOUG6aLx2AeaDao'? Use -v to see a list of the files searched for. Data/Aeson/Internal/Functions.hs:21:1: error: Failed to load interface for `Data.HashMap.Strict' Perhaps you haven't installed the profiling libraries for package `unordered-containers-0.2.8.0@unordered- containers-0.2.8.0-9vyhLlLaqmyDfOnbawvdcQ'? Use -v to see a list of the files searched for. }}} This is interesting because when we build aeson-compat (https://buildd.debian.org/status/package.php?p=haskell-aeson- compat&suite=sid) against the questionable build of aeson, we get {{{ Preprocessing test suite 'aeson-compat-test' for aeson-compat-0.3.6... [1 of 2] Compiling Orphans ( test/Orphans.hs, dist-ghc/build /aeson-compat-test/aeson-compat-test-tmp/Orphans.o ) [2 of 2] Compiling Main ( test/Tests.hs, dist-ghc/build/aeson- compat-test/aeson-compat-test-tmp/Main.o ) /usr/lib/haskell-packages/ghc/lib/x86_64-linux- ghc-8.0.2/aeson-1.0.2.1-CgbEAGwJWkq5wCUqDjmFHU/Data/Aeson/Types/ToJSON.hi Declaration for $fToJSONProxy_$ctoEncoding: Failed to load interface for `Data.Aeson.Encoding.Internal' There are files missing in the `aeson-1.0.2.1' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. Cannot continue after interface file error }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9805: Use TrieMaps to speed up type class instance lookup
by GHC 18 Jul '17

18 Jul '17

#9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, type class instance resolution is performed by doing a map lookup by type class, and then linearly matching against every instance. This is not great, and for a while, simonpj has been keen on using the TrieMap data structure in GHC, which has been previously used to implement a map from CoreExprs to various things (e.g. for CSE). What makes this a little tricky is that instance lookup isn't intended to be an exact match: we should unify so-called template variables and provide a substitution; furthermore, there may be multiple matches. After some prototyping, I think we should be able to make this work. The primary refactoring we have to do is *maintain the key associated with an entry in a TrieMap*. Unlike the current uses of TrieMaps, where it's acceptable to lose the underlying key associated with an entry in the TrieMap, we need to know the key when doing unification, because it may be reported in the substitution. There are a few knock-on effects of this: * We should add a method `foldWithKeyTM :: (Key m -> a -> b -> b) -> m a -> b -> b` to the `TrieMap` type class. * We need a variant of `UniqFM` which tracks the original key that was used. I propose we name it `UniqKM` (unique key map). A number of implementations of `TrieMap` need to be adjusted to use this instead of `UniqFM`. * Why can't we just represent keyed TrieMaps as `TypeMap (Type, a)`? It might be possible. An insurmountable difficulty would be if we need to know the partial key PRIOR to having finished traversing the TrieMap; however, for the parts of the unification algorithm I've implemented, this does not seem to be the case. The primary actual difficulty is that `Type` uses a named representation, whereas `TypeMap` keys are on-the-fly deBruijn numbered. There would at least be some annoying fiddliness. * Reversing the deBruijn numbered key into a `Type` is a bit goofy. Essentially, you need the reverse of the current `CmEnv`: a mapping from de Bruijn levels to the `Var` you've decided to allocate. (I've called this `CfEnv` in my prototype) * When we represent a TrieMap binder, we have to put the binder map on the OUTSIDE, as opposed to the inside as it is currently. Otherwise, we can't update the `CfEnv` with the new mapping before making the recursive call to fold-with-key. I'll attach the standalone Haskell file I used to prototype this, wherein I copy-pasted a lot of Haskell from GHC's source and implemented fuzzy map on a simplified version of `Type`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13989: use templateHaskell type checker panic
by GHC 17 Jul '17

17 Jul '17

#13989: use templateHaskell type checker panic -------------------------------------+------------------------------------- Reporter: chinaxing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm use acid-state, whci use TemplateHaskell to deriveSafeCopy, the following code will produce a panic {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Service.HAEventBroker where -- this module dispatch HAEvent to remote RDS-Console, -- if failed, persistent to locle storage and deliver later -- Event must keep ordered, aka FIFO -- import Model import Data.Acid import qualified Data.List as DL import Data.SafeCopy import Data.Typeable import Control.Concurrent import Control.Monad data HAEvent = HAEvent Int data EventQueue = EvQ [HAEvent] $(deriveSafeCopy 0 'base ''EventQueue) putEvent :: HAEvent -> Update EventQueue () putEvent e = do EvQ el <- get put $ EvQ (e:el) pollEvent :: Int -> Update EventQueue [HAEvent] pollEvent n = do EvQ el <- get let rl = DL.reverse el let t = DL.take n $ rl let r = DL.reverse $ DL.splitAt (length t) rl put $ EvQ r $(makeAcidic 'EventQueue ['putEvent, 'pollEvent]) publish :: Broker -> HAEvent -> IO () publish broker e = update broker (PutEvent e) consume :: HAEvent -> IO () consume e = return () newtype Broker = Broker { acidState :: AcidState (EventQueue [HAEvent]) } runBroker :: IO Broker runBroker = do broker <- openLocalStateFrom "haBroker/" (EventQueue []) putStrLn "I'm consuming the message queue ..." forkIO $ forever $ doConsume broker return broker where doConsume :: Broker -> IO () doConsume b = do ev <- update (acidState b) (PollEvent n) consume ev }}} stack ghci --ghc-options=-ddump-splices {{{#!hs /Users/LambdaCat/code/haskell/ha- admin/src/Service/HAEventBroker.hs:21:3-37: Splicing declarations deriveSafeCopy 0 'base ''EventQueue ======> instance SafeCopy EventQueue where putCopy (EvQ a1_awJ6) = contain (do { safePut_ListHAEvent_awJ7 <- getSafePut; safePut_ListHAEvent_awJ7 a1_awJ6; return () }) getCopy = contain (cereal-0.5.4.0:Data.Serialize.Get.label "Service.HAEventBroker.EventQueue:" (do { safeGet_ListHAEvent_awJ8 <- getSafeGet; ((return EvQ) <*> safeGet_ListHAEvent_awJ8) })) version = 0 kind = base errorTypeName _ = "Service.HAEventBroker.EventQueue" ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] get_awNI :: t_awNH[tau:1] (CHoleCan: get) [W] put_awOs :: t_awOr[tau:1] (CHoleCan: put) [W] get_awOF :: t_awOE[tau:1] (CHoleCan: get) [W] put_awOK :: t_awOJ[tau:1] (CHoleCan: put)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1399: better support for developing threaded applications in ghci
by GHC 14 Jul '17

14 Jul '17

#1399: better support for developing threaded applications in ghci -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: GHCi | Version: 6.6.1 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 mentheta): * cc: claus.reinke@… (removed) * cc: claus.reinke@…, Bulat.Ziganshin@…, mentheta (added) * failure: => None/Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1399#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13976: Defined but not used warning on records used by servant-client
by GHC 14 Jul '17

14 Jul '17

#13976: Defined but not used warning on records used by servant-client -------------------------------------+------------------------------------- Reporter: matthewleon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When generating an HTTP client through the servant-client lib (https://hackage.haskell.org/package/servant-client) if the various API record accessors go unused elsewhere, -Wunused-top-binds will generate warnings of the style "Defined but not used: `{accessor}`. I believe this is somewhat misleading, as the accessors are indeed "used" in the process of generating the client. Some sample code that will generate a warning for the `release` accessor: {{{ type API = "release" :> Capture "mbid" Mbid :> Get '[JSON] Listing type Mbid = UUID data Listing = Listing { release :: Text } deriving (Show, Generic) instance FromJSON Listing coverArtArchiveAPI :: Proxy API coverArtArchiveAPI = Proxy getListing :: Mbid -> ClientM Listing getListing = client coverArtArchiveAPI }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1