July 2015 - ghc-tickets

[GHC] #9735: Template Haskell for cross compilers (port from GHCJS)
by GHC 15 Dec '15

15 Dec '15

#9735: Template Haskell for cross compilers (port from GHCJS) -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHCJS supports Template Haskell by running it outside the compiler's process, with a different implementation of the Quasi type class. This can be done for other cross compilers too, if GHC gets an option to serialize Template Haskell requests and pass them to an external process. Someone started the work on this, but I think he stopped. I still have a document with a step by step plan to build an iOS cross compiler, with pointers to the relevant GHC and GHCJS code. https://github.com/ghcjs/ghcjs/wiki/Porting-GHCJS-Template-Haskell-to-GHC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9784: Allow Qualified Promoted Types
by GHC 15 Dec '15

15 Dec '15

#9784: Allow Qualified Promoted Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The program {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} fails with the error {{{ Foo.hs:7:17: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> Failed, modules loaded: none. }}} I believe the program above should compile without error. In the example above, I could make the code compile with my intended meanign using `Z`, `'Z`, or even `Foo.Z` in place of `Foo.'Z`, all of which refer to `Foo.'Z`. However, if there is also a vanilla type `Z` in scope and another promoted constructor `'Z` in scope, I have no way to disambiguate the reference to `'Z` in `bar`: - `Z` and `Foo.Z` refer to the vanilla type - `'Z` could be from the promoted `MyNat` constructor, or from the other module Concretely, I could import `Data.Type.Natural` from [https://hackage.haskell.org/package/type-natural type-natural], which also defines the promoted constructor `'Z`. {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy import Data.Type.Natural data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} In this case, there is no way for me to indicate that `bar` has the type `Foo.'Z -> Int` As a side note, if I do as the error suggests and use`RankNTypes`, I get the same error message. It's a bit strange for GHC suggest adding an extension that is already enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances
by GHC 15 Dec '15

15 Dec '15

#9820: Apparently inconsistent behaviour in the presence of OverlappingInstances -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This report is inspired by http://stackoverflow.com/questions/27051640 /strange-behavior-when-adding-constraint-to-instance I'm not sure if it is a bug, but it certainly feels strange and inconsistent to me, so I'd like to get some clarification. Here's a self-contained example of the behaviour: {{{#!hs {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} module Overlap where class C a where foo :: a -> a instance C a where foo = id instance C Int where foo = (+1) -- Note that this one does not mention class C anywhere: class D a where bar :: a -> a instance D a where bar = foo -- this works and picks the 'C a' instance always -- The following does not compile without IncoherentInstances: {- baz :: a -> a baz = foo -} }}} I'm surprised that the definitions of `bar` and `baz` are treated differently. Shouldn't they either both require `IncoherentInstances`, or both work? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9846: GHC --make should also look for .hi, not only for .hs
by GHC 15 Dec '15

15 Dec '15

#9846: GHC --make should also look for .hi, not only for .hs -------------------------------------+------------------------------------- Reporter: larsrh | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, `ghc --make` will only consider .hs source files from the include path. Example (assuming `Library` can't be resolved from the package database): `A.hs` {{{#!hs module A where import B import Library }}} `B.hs` {{{#!hs module B where }}} Compiling these files with `ghc --make -Idir A.hs B.hs` will succeed only if GHC finds a `Library.hs` file. In a thread on [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-November/025476.html glasgow-haskell-users], Simon proposed relaxing this constraint; namely: In `--make` mode, when encountering an import `X`, GHC will try the following in order: 1. resolve the import from a package 2. search the include path for `X.hs` or `X.lhs` 3. search the include path for `X.hi` It already does 1 and 2, and this proposal would add 3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9862: defined but not used errors on Solaris/SPARC
by GHC 15 Dec '15

15 Dec '15

#9862: defined but not used errors on Solaris/SPARC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Incorrect Difficulty: Unknown | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I recently tried building GHC on Solaris and I got a ton of these files when compiling the bootstrapping copy of Cabal: {{{ "/afs/sipb/user/ezyang/ghc-7.8.2/usr/bin//ghc" -H32m -O -Werror -Wall -H64m -O0 \ -optc-Werror -optc-Wall -optc-fno-stack-protector \ \ --make utils/ghc-cabal/Main.hs -o utils/ghc- cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings- deprecations \ -DCABAL_VERSION=1,21,1,0 \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src -DGENERICS \ -ilibraries/filepath \ -ilibraries/hpc \ -w "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... "rm" -f utils/ghc-pkg/dist/build/Version.hs echo "module Version where" >> utils/ghc- pkg/dist/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs echo "version = \"7.9.20141204\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetOS = \"solaris2\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetARCH = \"sparc\"" >> utils/ghc-pkg/dist/build/Version.hs done. [ 1 of 86] Compiling Distribution.Compat.CreatePipe ( libraries/Cabal/Cabal/Distribution/Compat/CreatePipe.hs, bootstrapping/Distribution/Compat/CreatePipe.o ) cc1: warnings being treated as errors /tmp/ghc322370_0/ghc322370_21.hc: In function ‘s1xM_entry’: /tmp/ghc322370_0/ghc322370_21.hc:21:0: error: label ‘_c312’ defined but not used /tmp/ghc322370_0/ghc322370_21.hc: In function ‘s1xK_entry’: /tmp/ghc322370_0/ghc322370_21.hc:63:0: error: label ‘_c31b’ defined but not used }}} Maybe the 7.8.2 codegen which I bootstrapped from is buggy in some way? It makes it mildly difficult to actually validate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9865: Comonads in base library
by GHC 15 Dec '15

15 Dec '15

#9865: Comonads in base library -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comonads are useful as heck, and should be in the base library. This could allow codo notation (e.g. https://www.cl.cam.ac.uk/~dao29/publ/codo- notation-orchard-ifl12.pdf ) in the future. It shouldn't be hard at all to do - just basically copy Edward's comonad package :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9911: Pattern synonyms with no signatures should yield warnings
by GHC 15 Dec '15

15 Dec '15

#9911: Pattern synonyms with no signatures should yield warnings -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: PatternSynonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When `-fwarn-missing-signatures` is turned on, GHC should emit warnings for pattern synonyms with no signatures -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9923: Offer copy-on-GC sliced arrays
by GHC 15 Dec '15

15 Dec '15

#9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It's sometimes useful to split an array and send each part on to a different computation. Slicing works very well for this sort of thing, as long as both computations run to completion or become garbage at about the same time. It can work badly, however, if one computation is completed or abandoned and the other is retained—it may only hold a tiny slice, but that's enough to keep the entire array alive. The alternative, currently, is to copy the array to form two new arrays. This gets rid of the retention problem, but introduces a performance problem. One way to solve these problems might be to offer sliced arrays supported by the RTS. On collection, the garbage collector would copy each slice separately, turning it into an independent (and independently collectible) array. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9931: Option to truncate Show output in ghci REPL
by GHC 15 Dec '15

15 Dec '15

#9931: Option to truncate Show output in ghci REPL -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Perhaps a configurable limit, with a :more (or :all) that would give you more if you ask for it. Seems pretty harmless and could help usability a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9974: Allow more general structural recursion without UndecidableInstances
by GHC 15 Dec '15

15 Dec '15

#9974: Allow more general structural recursion without UndecidableInstances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I bet this is a duplicate, but I couldn't find it. A simple example from the `HList` package: {{{#!hs type family HRevApp (l1 :: [k]) (l2 :: [k]) :: [k] type instance HRevApp '[] l = l type instance HRevApp (e ': l) l' = HRevApp l (e ': l') }}} GHC 7.8.3 and 7.11 both complain about the second instance if `UndecidableInstances` is turned off, because the application is no smaller than the index head. Moreover, the same error occurs when the type family is closed. However, GHC already knows how to separate term-level definitions into recursive groups; applying this same analysis to the type family above would reveal that `HRevApp` is structurally recursive, and therefore decidable. It is key, in this case, that the instance for `[]` is visible from the instance declaration for `e ': l`, so such an analysis could only be done in module dependency order for open type families. Side note: there is a (nasty) workaround available for the problem in this case: {{{#!hs type family HRevApp' (l1 :: [k]) (l1' :: [k]) (l2 :: [k]) :: [k] type instance HRevApp' t '[] l = l type instance HRevApp' (e ': l) (e' ': l') l'' = HRevApp' l l' (e ': l'') type HRevApp l1 l2 = HRevApp' l1 l1 l2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2