January 2015 - ghc-tickets

Re: [GHC] #5821: SPECIALISE fails with a cryptic warning
by GHC 08 Jan '15

08 Jan '15

#5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang * milestone: 7.12.1 => 7.10.1 Comment: I think we can nail this for 7.10. I'll attempt a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5821#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9966: Allow switching to different monads in GHCi
by GHC 08 Jan '15

08 Jan '15

#9966: Allow switching to different monads in GHCi -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHCi can evaluate individual `IO` actions, e.g. {{{ ghci> writeFile "foo.txt" "bar" ghci> readFile "foo.txt" bar }}} but, as far as I know, this doesn't extend to other monads. Instead you have to compose an entire computation and then run it with the standard eliminators, e.g. {{{ ghci> evalState 0 (put 1 >> get) 1 }}} It would be quite nice if we could tell GHCi to temporarily jump into a different top-level monad, e.g. {{{ -- we start in IO as usual ghci> :monad runState 0 -- now we're in `State Int` with the initial state set to 0 ghci> put 1 -- we can evaluate individual State actions without the ceremony of `runState`, -- and having to track the updated state ourselves between actions ghci> get 1 ghci> :monad IO -- now we're back in IO }}} I'm not sure how feasible this is (it seems tricky), but it would provide a very nice UX for GHCi in the context of larger Haskell applications. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4316: Interactive "do" notation in GHCi
by GHC 08 Jan '15

08 Jan '15

#4316: Interactive "do" notation in GHCi -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 4459 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe, hvr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4316#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters
by GHC 07 Jan '15

07 Jan '15

#8486: cannot derive new-typeable instances for promoted data types taking parameters ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, The following code shows the issue: {{{ {-# LANGUAGE DataKinds, DeriveDataTypeable, KindSignatures, PolyKinds, StandaloneDeriving #-} import Data.Typeable import GHC.TypeLits data T (a :: [*]) = T deriving (Typeable) t = T :: T [Int, Double] deriving instance Typeable '[] {- *Main> typeOf t <interactive>:24:1: No instance for (Typeable (* -> [*] -> [*]) ((':) *)) arising from a use of ‛typeOf’ In the expression: typeOf t In an equation for ‛it’: it = typeOf t -} }}} ghc7.7-20131004 doesn't allow either of the following: {{{ deriving instance (Typeable a, Typeable b) => Typeable (a ': b) -- or deriving instance Typeable (':) }}} On ghc-7.6 I could write my own `instance Typeable (T a)`, but this has been disabled it seems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9111: base should export Typeable instances of its promoted data constructors
by GHC 07 Jan '15

07 Jan '15

#9111: base should export Typeable instances of its promoted data constructors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As initially reported in #8486, `base` does not export `Typeable` instances for its promoted data constructors, as witnessed by this: {{{ {-# LANGUAGE DataKinds #-} import Data.Typeable x = typeRep (Proxy :: Proxy True) }}} yields {{{ No instance for (Typeable 'True) arising from a use of ‘typeRep’ In the expression: typeRep (Proxy :: Proxy True) In an equation for ‘x’: x = typeRep (Proxy :: Proxy True) }}} It is indeed possible to derive these instances locally with standalone deriving, but that seems very problematic, should multiple modules do that independently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

Re: [GHC] #1851: "make install-strip" should work
by GHC 07 Jan '15

07 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) * failure: None/Unknown => Building GHC failed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1851: "make install-strip" should work
by GHC 07 Jan '15

07 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * status: closed => new * failure: => None/Unknown * version: 6.8.1 => 7.8.4-rc1 * milestone: 6.8.2 => * owner: igloo => * resolution: fixed => Comment: This is fixed in bindist, but still doesn't work in the source distribution. {{{ # make install-strip ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final install-strip make[1]: *** No rule to make target `install-strip'. Stop. make: *** [install-strip] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9946: Expose the source location of template-haskell Names
by GHC 06 Jan '15

06 Jan '15

#9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've often wanted to know where a particular `Name` is defined (specifically the filepath), but as far as I can tell, template-haskell doesn't currently support this. It'd be really nice to have a function {{{#!hs nameLoc :: Name -> Loc }}} to expose the definition site of the `Name`. I think this should be fairly straightforward to add since GHC carries the definition site around with its `Name`s, but I've never looked at the TH internals. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9872: Runing type functions is too slow
by GHC 06 Jan '15

06 Jan '15

#9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Gergo reports, prompted by [http://stackoverflow.com/questions/26538595/more-efficient-type-level- computations-using-type-families this question on Stack Overflow]. I wrote some code today using closed type families and datakinds. Also, as a baseline, I typechecked the code using open type families from the original question. The two files are attached as slow1.hs and slow2.hs below. On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking time, respectively! Is this some known regression, something surprising, or is 'perf' simply not the right build flavour for this kind of comparison? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

Re: [GHC] #7485: Tuple constraints not properly kinded
by GHC 06 Jan '15

06 Jan '15

#7485: Tuple constraints not properly kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): What was my "original suggestion"? (!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7485#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0