- ghc-tickets - Haskell.org

[GHC] #12765: Don't optimize coercions with -O0
by GHC 26 Oct '16

26 Oct '16

#12765: Don't optimize coercions with -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During the call today Simon and I discussed the possibility of omitting coercion optimization from the desugarer's simple optimization (`simpleOptPgm`) when compiling with `-O0`. The justification here was to perhaps speed-up unoptimized compilation times for programs like that of #12506, which has very large coercions (presumably due to #8095). The rationale was that while this first pass of coercion simplification during desugaring may reduce the size of some of these coercions, we only walk over them once more during code generation, so there's little benefit given the cost. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2721: Newtype deriving doesn't work with type families
by GHC 26 Oct '16

26 Oct '16

#2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 8.2.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2636 * milestone: => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2721#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC
by GHC 26 Oct '16

26 Oct '16

#4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/T4114a,b,c,d Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | Phab:D2050 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4114#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:17 simonpj]: > So I'm unconvinced that this is worth the bother. I completely agree, not only because it might be over-constraining, but in some cases it might even yield redundant constraints, as in this example: {{{#!hs {-# LANGUAGE TypeFamilies #-} class C a where data D a c :: a -> a -> Bool instance Eq a => C [a] where newtype D [a] = DList [a] deriving Show c = (==) }}} This would, under the proposal in this ticket, yield: {{{#!hs instance (Eq a, Show a) => Show (D [a]) }}} which isn't what we want at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I think it's more than just #11008. The question of this ticket is just "what context should GHC infer for a 'deriving' clause." But the ticket concerns the specific case of a `data instance` inside a `class` instance decl, thus: {{{ instance <context> => C (T a b) where data D (T a b) = D1 a | D2 b }}} Now arguably, whether or not the `deriving Eq` part ''needs'' `<context>` it would do no harm to add it, so we get the derived instance {{{ instance <context> => Eq (DT a b) where (==) = <blah> }}} (where `DT` is the representation data type for `D (T a b)`). The point is that `<context>` might help satisfy the `Eq` constraints arising from `<blah>`. Max argues that `<context>` must already be satisfied (because the class instance holds). But that's not really true {{{ f x y = D1 x == D2 y }}} Here we need equality on `DT` but we don't need `C (T a b)`. So `<context>` might be over-constraining. So I'm unconvinced that this is worth the bother. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, the comparison to `-XDatatypeContexts` is definitely a compelling argument for the current behavior. I'll quit my job as devil's advocate, then. In that case, that cements my opinion that associated data family instances should be totally unrelated to the instance context of the parent instance, and moreover, that the bug is really just a duplicate of #11008 in disguise, as the fix for this issue would be improving GHC's ability to infer exotic constraints. Should we close it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): I would expect it to type check, because an associated family instance is sugar for an ordinary data family instance and I can't understand what it would mean to put a constraint on such an instance (or why I would want to; it feels like the old datatype contexts). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What I mean is: if you had this code (using the example in comment:10): {{{#!hs c' :: [a] -> [a] -> Bool c' = c }}} then it would fail to typecheck, as there's no `Eq a` constraint, as mandated by the context in `instance Eq a => C [a]`. What I am asking is simply: should this `Eq a` constraint also be required for the associated family instances as well? That is, should this typecheck, even though it has no `Eq a` constraint? {{{#!hs dlist :: D [a] dlist = DList [] }}} (Currently, it //does// typecheck.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can data family (or type family) instances even have contexts? What is that supposed to mean? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 25 Oct '16

25 Oct '16

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I would also be inclined to say "use the standalone route", for the reason that I don't see any reason why the `deriving` clause would infer `Eq (Associated a)` given the current state of things. I was merely imagining a hypothetical scenario in which data family instances //would// reasonable infer such a constraint when deriving instances. If data family instances were more tightly intermingled with their parent instances in terms of instance contexts, I could envision this being the case. P.S. Do you know why GHC decides `DList [] :: D [a]` instead of `DList [] :: Eq a => D [a]`? That is, why GHC chose to make associated data family instance contexts separate from their parent instances' contexts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0