August 2013 - ghc-tickets

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): OK, yes, I missed the `[ = constrs ]` part of the grammar. Yes, `EmptyDataDecls` is part of H2010. And yes, clause (6) in the [http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-182000… deriving appendix] explicitly dis-allows `deriving( Eq )`, but here I think it would be OK for GHC to be a little more generous than the standard. That is, with `EmptyDataDecls` (or `Haskell2010`) we'd accept {{{ data T deriving( Eq ) }}} whereas H2010 would reject it. But failing to reject is very unlikely to break anyone's code. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted
by GHC 16 Aug '13

16 Aug '13

#5539: GHC panic - Simplifier ticks exhausted ---------------------------------------+---------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by ghorn): sorry for the spam, I found a smaller example: {{{ {-# OPTIONS_GHC -Wall #-} module Main ( main ) where import Foreign.Ptr ( Ptr ) import Foreign.Marshal ( malloc ) main :: IO () main = do _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) return () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5539#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted
by GHC 16 Aug '13

16 Aug '13

#5539: GHC panic - Simplifier ticks exhausted ---------------------------------------+---------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by ghorn): Ignore the comment above about cabal. Ghc will reproduce the bug with -O1 {{{ $ ghc -O1 Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:Foreign.Storable.$fStorableInt_$csizeOf{v r3z} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 7926 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5539#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted
by GHC 16 Aug '13

16 Aug '13

#5539: GHC panic - Simplifier ticks exhausted ---------------------------------------+---------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by ghorn): Here is another small test case: {{{ {-# OPTIONS_GHC -Wall #-} module Main ( main ) where import Foreign.Ptr ( Ptr ) import Foreign.Marshal ( malloc, mallocArray ) main :: IO () main = do _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- malloc :: IO (Ptr Int) _ <- mallocArray 10 :: IO (Ptr Int) _ <- mallocArray 10 :: IO (Ptr Int) _ <- mallocArray 10 :: IO (Ptr Int) return () }}} This will fail as a bare-bones cabal project, but ghc --make will successfully compile it. I'm on GHC 7.6.3 on 64-bit Debian. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5539#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by thoughtpolice): I'm very confused here. When Simon Marlow announced H2010, EmptyDataDecls is specifically mentioned as part of the revision: https://groups.google.com/forum/#!topic/fa.haskell/-muu4dzUBJo Furthermore, the haskell-prime wiki makes this mention in regards to the extension: http://ghc.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls > The only real issue is whether or not to allow the optional deriving clause after an empty declaration, and, if not, on what stage to rule them out. Clearly, as there are no data constructors over which to define functions, derived instances would (for consistency) have to be everywhere undefined. GHC seems to syntactically allow a deriving clause after an empty data declaration, but the treats it as a contextual error since no interesting instances can be defined. Presumably the reasoning was that this gives a more regular syntax and better error messages than ruling out deriving for empty declarations syntactically. But the point is that there is a choice. > For this extension, probably the best course of action is to follow GHC and allow deriving () clauses for empty data declarations. That way no deriving clause and deriving () still have the same semantics. To do this, we syntactically allow all deriving clauses for empty data, but semantically limit the clauses to deriving (). (Just to note, this is in fact how it now works - 'data Foo deriving ()' works just fine, but 'data Foo deriving Eq' is a contextual error.) So, I don't think we're deviating from the standard at all in fact, at least based on the proposal and what Simon said. Perhaps these parts of the standard document were simply overlooked during the editorial process, hence the inconsistency? Under my interpretation, H2010 absolutely has EmptyDataDecls, and they are "ordinary" data types. Now we are back to the original question, which the proposal somewhat alluded to. I see this as two separate points: * What is more consistent, to reject the instance or create the vacuous one? My view is already clear here (that 'ordinary' data types with trivial vacuous instances - where there are no constructors - should also be derivable.) * The standard however, specifically denies this interpretation, as does the Haskell' proposal (delta pt 6.) There are two options: * Put this behavior under a new flag? Above, Krzysztof mentioned a possible `-XEmptyDeriving`. * Change the semantics of `-XEmptyDataDecls` and deviate specifically? This is a delicate point obviously. Retroactively changing extensions is always annoying, but we've been here before, and backwards compatibility with a manual instance is doable. This logic kind of flies in the face of doing it anyway, at face value - but this is relevant to users. Some libraries are very long-term supported, and a 'legacy style' must be dealt with. They can simply write manual instances and nothing will ever break. Other people who don't care can just use the new behavior. Feasibly, whatever we do, this minor amendment could be proposed for Haskell 2014. If this is the case, perhaps we should use a new flag. I'm personally in favor of doing whatever users want if we can get any consensus, because ultimately they maintain the libraries and will possibly see the consequences of this change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by monoidal): Haskell 2010 clearly has empty data decls. We've got in section 4.2.1 topdecl -> data [context =>] simpletype [= constrs] [deriving] Note that "= constrs" is in square brackets [] which denote optional part. There's also this part: "This declaration introduces a new type constructor T with zero or more constituent data constructors". Plus, the announcement of the standard contained a list of additions, including empty data declarations. If there's any contradicting information, I would call it a typo in the standard. However, there's a quirk: the deriving clause in H2010 is allowed only on nonempty data decls. I can't work on the ticket in this month - sorry. To the patch author: I think we should be consistent with Eq, Ord etc. One way would be removing cond_stdOK altogether. This should make conditions for standalone deriving and normal deriving completely equivalent, but it is overly permissive in regard to standard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by goldfire): Good point about the fact that H2010 does '''not''' have empty data decls. But, then, GHC's interpretation of H2010 is incorrect, as setting H2010 as the language turns on `EmptyDataDecls`. Personally, I don't love straying from the standard, but it may be best not to unnecessarily break code here by "fixing" this deviation from the standard. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Changes (by simonpj): * cc: omeragacan@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): There was some follow-up email on ghc-devs about this. (But let's accumulate comments here.) My summary * If we have `EmptyDataDecls` then surely {{{ data T deriving( Eq ) }}} should work, just as well as standalone deriving {{{ data T deriving Eq T }}} The two must behave the same. * Surely all the built-in classes (Eq, Show, Ord etc) should derive for with `EmptyDataDecls` too. * Haskell 2010 doesn't have `EmptyDataDecls` (eg the [http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2 data type chapter] specifies n>0 constructors). But oddly the [http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-182000… deriving appendix] clause 6 says that nothing is derived if there are no constructors. I think we should just ignore clause 6, since H2010 doesn't have empty data types. * It would be better if the `error "Void Eq"` mentioned the data type. More like `error "Eq on empty data type T"`. Might you do those things, Omer? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 16 Aug '13

16 Aug '13

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. ----------------------------------------------+---------------------------- Reporter: jpbernardy | Owner: monoidal Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by simonpj): Omer writes: I just started GHC development made a commit for ticket 7401: http://ghc.haskell.org/trac/ghc/ticket/7401 My patch is here: https://github.com/osa1/ghc/commit/3ec257ff48372de30df59cd8854ce28954c9db95 `make test` succeeds. My test case for this patch is something like this: {{{ data D deriving Eq main :: IO () main = print ((undefined :: D) == (undefined :: D)) }}} example: {{{ haskell$ ./ghc/inplace/bin/ghc-stage2 --interactive derive.hs GHCi, version 7.7.20130806: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( derive.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () }}} This behavior (returning True) is consistent with standalone deriving version: {{{ haskell$ cat derive_standalone.hs {-# LANGUAGE StandaloneDeriving #-} data D deriving instance Eq D main :: IO () main = print ((undefined :: D) == (undefined :: D)) haskell$ ./ghc/inplace/bin/ghc-stage2 --interactive derive_standalone.hs GHCi, version 7.7.20130806: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( derive_standalone.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () ghci> Leaving GHCi. }}} However, if you want (==) implementation in this case to be `error "Void (==)"`, I think I can also do that by first fixing the code generated by `StandaloneDeriving` extension and then fixing my current patch. Any comments and reviews would be appreciated! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0