August 2017 - ghc-tickets

[GHC] #14147: Confusing error messages with PolyKinds and superclasses
by GHC 23 Aug '17

23 Aug '17

#14147: Confusing error messages with PolyKinds and superclasses -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: new 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 program compiles fine: {{{#!hs {-# LANGUAGE FlexibleInstances #-} import Data.Typeable newtype Tagged t v = Tagged v deriving Typeable class (Typeable t) => MyClass t where classF :: t -> Int instance Typeable t => MyClass (Tagged t Int) where classF (Tagged n) = n }}} But if I add `PolyKinds` to the `LANGUAGE` pragma I get: {{{ code/junk/typeable-problems.hs:17:10: error: • Could not deduce (Typeable k) arising from the superclasses of an instance declaration from the context: Typeable t bound by the instance declaration at code/junk/typeable-problems.hs:17:10-45 • In the instance declaration for ‘MyClass (Tagged t Int)’ | 17 | instance Typeable t => MyClass (Tagged t Int) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Which is very confusing since I don't have a `k` variable anywhere. Adding `-fprint-explicit-kinds` is somewhat better: {{{ code/junk/typeable-problems.hs:17:10: error: • Could not deduce (Typeable * k) arising from the superclasses of an instance declaration from the context: Typeable k t bound by the instance declaration at code/junk/typeable-problems.hs:17:10-45 • In the instance declaration for ‘MyClass (Tagged k t Int)’ | 17 | instance Typeable t => MyClass (Tagged t Int) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But still confusing. It doesn't really point me towards the solution - specifying that the kind of t is `*` explicitly - if I don't already know how the extension works. It's also annoying that turning on an extension causes a type error, but I don't know if that's fixable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pggiarrusso): If anybody is unaware and interested: the latest work on the topic is "Stream Fusion, to Completeness" (https://strymonas.github.io/) and in Sec. 8 it seems to claim advantages relative to the HERMIT work (though I've only skimmed this), so that might be relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13702: GHC can't produce position independent executables
by GHC 23 Aug '17

23 Aug '17

#13702: GHC can't produce position independent executables -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Due to #12759 we unconditionally pass `-no-pie` to GCC. However, there are legitimate reasons to want a PIE. We should have a `-fPIE` flag to match `-fPIC`, requesting that the compiler produce a position-independent executable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14148: initTc: unsolved constraints
by GHC 23 Aug '17

23 Aug '17

#14148: initTc: unsolved constraints --------------------------------------+---------------------------------- Reporter: robertpergl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- || ghc: panic! (the 'impossible' happened) || (GHC version 8.0.2 for x86_64-unknown-linux): || initTc: unsolved constraints || WC {wc_insol = || [W] ltail_ae2e :: t_ae2d[tau:1] (CHoleCan: ltail) || [W] lhead_ae2h :: t_ae2g[tau:1] (CHoleCan: lhead)} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 23 Aug '17

23 Aug '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Saizan): This is great, but in some cases generating code for all the imported modules is too much. Would it make sense to have {-# OPTIONS_GHC -fobject-code #-} change the HscTarget for the module, so that authors can fine-tune for which modules code needs to be generated? (together the old behavior of -fno-code, I mean) Currently having that pragma seems to have no effect. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14142: Can't invert -dno-debug-output
by GHC 23 Aug '17

23 Aug '17

#14142: Can't invert -dno-debug-output -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- `mk/flavours/validate.mk` sets {{{ GhcStage2HcOpts = -dno-debug-output }}} and there is no way to undo it. E.g. you can't add {{{ GhcStage2HcOpts += -ddebug-output }}} to your `mk/validate.mk` does not work. We should add `-ddebug-output` to invert it. Easy task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:50 simonpj]: > > if we would employ some other mechanism than rewrite rules to specialise call sites > > I don't know what you have in mind here. Would you care to elaborate? Right, that's quite a bummer. I'll probably have to develop a deeper understanding of how `SpecConstr` and the rewrite rule mechanism works before I can answer this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > if we would employ some other mechanism than rewrite rules to specialise call sites I don't know what you have in mind here. Would you care to elaborate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf1337@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 23 Aug '17

23 Aug '17

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): On my journey through fusion land, I fell in love with the idea of stream fusion and spent quite some time thinking about the `concatMap` problem. Apart from the HERMIT approach based on rewriting a (albeit large) subset of `concatMap` calls, I think the solution lies in call-pattern specialisation of function arguments, as already recognised in section 6.2 of the [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/07/spec-constr.pdf original paper on call-pattern specialisation]. The paper goes on to argue that it's too brittle to have rules matching on lambda terms. But then again, I don't see why we even need a RULE matching on a specific lambda term (or even terms with `exprArity` > 0), as these things are pretty much unique everytime they occur. E.g., having a RULE deduplicate specialisations would probably not help much anyway. So, if we would employ some other mechanism than rewrite rules to specialise call sites, as I understand `SpecConstr` currently does, I think we would be fine, wouldn't we? At least this could get rid of the `concatMap` roadblock, are there any others I'm not aware of? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0