July 2018 - ghc-tickets

[GHC] #14146: Can GHC propose kind restrictions?
by GHC 17 Dec '18

17 Dec '18

#14146: Can GHC propose kind restrictions? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 is UX. As my code gets more polykinded I find myself in situations such as these all the more often {{{#!hs instance (Comonad f, Representable f, Comonad g, Representable g) => Comonad (Compose f g) where extract = undefined duplicate = undefined instance ComonadApply (Compose f g) where (<@>) = undefined }}} {{{ /tmp/a.hs:20:10-35: error: • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration • In the instance declaration for ‘ComonadApply (Compose f g)’ | 20 | instance ComonadApply (Compose f g) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. }}} It would help me if GHC looked up a `Comonad (Compose _ _)` instance, compared the kinds {{{#!hs Comonad (Compose (f :: Type -> Type) (g :: Type -> Type) :: Type -> Type) ComonadApply (Compose (f :: k -> Type) (g :: Type -> k) :: Type -> Type) }}} a simple suggestion like this would be helpful {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a kind signature (ComonadApply (Compose (f :: Type -> Type) g)). }}} Even more amazing would be {{{ • No instance for (Comonad (Compose f g)) arising from the superclasses of an instance declaration Try adding a context (Comonad f, Representable f, Comonad g, Representable g) => ComonadApply (Compose f g) }}} Which the compiler could in theory guess, since following GHC's suggestion iteratively you end up with {{{#!hs ComonadApply (Compose (f :: Type -> Type) g) -- ==> add (Comonad f) to the context of the instance declaration Comonad f => ComonadApply (Compose f g) -- ==> add (Comonad g) to the context of the instance declaration (Comonad f, Comonad g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g) => ComonadApply (Compose f g) -- ==> add (Representable f) to the context of the instance declaration (Comonad f, Comonad g, Representable g, Representable f) => ComonadApply (Compose f g) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13992: Error message, room for improvement (polykinds)
by GHC 17 Dec '18

17 Dec '18

#13992: Error message, room for improvement (polykinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something like {{{#!hs -- • No instance for (Show (Compose Proxy Proxy a)) -- arising from the 'deriving' clause of a data type declaration -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Show (FlipProxy a)) {-# Language DerivingStrategies, GeneralizedNewtypeDeriving, PolyKinds, KindSignatures #-} import Data.Functor.Compose import Data.Proxy import Data.Kind newtype FlipProxy a = FlipProxy_ (Compose Proxy Proxy a) deriving newtype Show }}} where the solution is to constraint the kind of `a :: Type`, it would be nice if GHC could reference kind variables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15333: Weird cachegrind results for binary-trees
by GHC 14 Dec '18

14 Dec '18

#15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: NoFib | Version: 8.5 benchmark suite | 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'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings. Check out the most recent version of `nofib` and run the following script: {{{#!sh #! /usr/bin/env zsh sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt1 sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt2 valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace }}} This will compile two versions of `binary-trees`, one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt1`) to allocate more than the version without (`bt2`). Indeed, the output of `+RTS -s` suggests that: {{{ $ ./bt1 12 +RTS -s ... 43,107,560 bytes allocated in the heap ... $ ./bt2 12 +RTS -s ... 43,116,888 bytes allocated in the heap ... }}} That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO). Compare that to the output of the above cachegrind calls: {{{ $ valgrind --tool=cachegrind ./bt1 12 > /dev/null ... I refs: 118,697,583 ... D refs: 43,475,212 ... $ valgrind --tool=cachegrind ./bt2 12 > /dev/null ... I refs: 116,340,710 ... D refs: 42,523,369 ... }}} It's the other way round here! How's that possible? Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw. I checked this on GHC 8.2.2 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension)
by GHC 14 Dec '18

14 Dec '18

#14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13126 #9224 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Implement Underscores in Numeric Literals Proposal. GHC supports various numeric literals such as decimal, octal, hexadecimal, binary, and floating point numbers. However, large numeric literals are hard to read. This proposal improves the readability, quality, expressiveness of numeric literals. This proposal allows underscores to numeric literals when the `NumericUnderscores` language extension is enabled. Underscores (`_`) in numeric literals are simply ignored. The specification of the feature is available here:\\ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009 -numeric-underscores.rst For a discussion:\\ https://github.com/ghc-proposals/ghc-proposals/pull/76 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14345: Warning when linking with C++ code
by GHC 14 Dec '18

14 Dec '18

#14345: Warning when linking with C++ code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When linking with a C++ file, GHC 8.2.1.20170928 produces a warning because it runs gcc with 'std=gnu99', even when I pass 'std=c++11' to cc- options (when using stack, I see that the command is something like 'gcc std=gnu99 ... std=c++11', so it isn't *ignoring* my input, just appending it.) I believe this warning is new as of 8.2. The attached example demonstrates the problem: {{{ > cabal configure > cabal build cc1plus: warning: command line option ‘-std=gnu99’ is valid for C/ObjC but not for C++ cc1plus: warning: command line option ‘-std=gnu99’ is valid for C/ObjC but not for C++ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15080: List Operators Sorted by Precedence in GHCi
by GHC 14 Dec '18

14 Dec '18

#15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: operator | Operating System: Unknown/Multiple precedence | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a large project, it can be difficult to keep track of the precedence of operators. It would be a nice quality-of-life improvement if there were a GHCi command to list the current operators in scope by precedence. It could list them in a table like this: {{{ :operators | prec | nonassoc | leftassoc | rightassoc | |------+----------+-----------+------------| | 9 | !! | | . | | 8 | | | ^ ^^ ** | | 7 | * / | | | | 6 | + - | | | | 5 | | | : ++ | | 4 | | == | | }}} Perhaps it could list all infix operators, as well as functions that have a fixity declaration? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channal type
by GHC 13 Dec '18

13 Dec '18

#15267: Extend TVar/MVar to N capacity / Add primitive channal type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | 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 current concurrent primitives `TVar` and `MVar` have a fixed single capacity for holding the value to be synchronized. This pose great limitations on implementing many higher level concurrent structures efficiently, e.g. bound channel, semaphore, resource pool, etc. For example current <semaphore's implementation http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Control.Concurren…> is not ideal due to the extensive usage of multiple `MVar` s. If we have a good `BoundedChan a` type, semaphores can be easily implemented with `BoundedChan ()`. Currently we have various bound channel implementations, but these implementations are often not very efficient or too complex. For example the `BoundedChan` from <BoundedChan http://hackage.haskell.org/package/BoundedChan-1.0.3.0/docs/Control- Concurrent-BoundedChan.html> is based on an array of `MVar` s, thus consumes much more memory than a primitve channel which only have to record parked `StgTSO` s. I'm thinking adding something like: ``` typedef struct { StgHeader header; struct StgMVarTSOQueue_ *head; struct StgMVarTSOQueue_ *tail; StgInt capacity; // the channel's capacity StgInt read_index; // the reading end's index StgInt write_index; // the writing end's index StgClosure *payload[]; // payload array in continuous memory } StgMChan; ``` I still can't work out all the details, but I'm confident something similar to this will work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules
by GHC 13 Dec '18

13 Dec '18

#14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed. One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs
by GHC 12 Dec '18

12 Dec '18

#11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10458 #5289 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular when compiling on NixOS, but also in many other situations, it is often needed to pass --extra-lib-dirs / --extra-include-dirs to cabal/stack, to help GHC find required system libraries. This works fine for GHC, but not GHCi, and therefore also not Template Haskell code. Minimal example attached. Try it in an environment where libz is not in a standard location, e.g. inside a nix-shell. Note that if you remove the template Haskell splice in Main.hs, the code compiles just fine. This affects GHC 7.10.2, but also HEAD from 2015-08-28, even one including Tamar Christina's 5d841108acef950fed6a5e608ac9b18e7431aa87 commit cherry- picked. I haven't been able to test more recent HEAD, because of unrelated compilation issues. I surmise that a fix to #10458, which currently blocks using HaskellR in GHCi, would also fix this, but I'm not sure. The error message I get is different: {{{ $ stack build --skip-ghc-check --extra-lib- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/lib --extra- include- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/include b-0.1.0.0: build Preprocessing executable 'b' for b-0.1.0.0... [2 of 2] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.23.0.0/build/b/b-tmp/Main.o ) <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) -- While building package b-0.1.0.0 using: /home/mboes/.stack/setup-exe-cache/setup-Simple- Cabal-1.23.0.0-x86_64-linux-ghc-7.11.20150828 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.23.0.0/ build exe:b --ghc-options " -ddump- hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports
by GHC 12 Dec '18

12 Dec '18

#14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- It seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance, {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import qualified Data.Maybe as M λ> M.fromJusr <interactive>:2:1: error: Not in scope: ‘M.fromJusr’ Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe) No module named ‘M’ is imported. λ> }}} I suppose there is the question of whether we consider `M` to be a "module" here; I would argue that I imported it and therefore the message is at very least a bit misleading. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4