#10318: Cycles in class declaration (via superclasses) sometimes make sense.
-------------------------------------+-------------------------------------
Reporter: ekmett | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 7.10.1
checker) |
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: GHC rejects | Unknown/Multiple
valid program | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Simon Peyton Jones ):
In [changeset:"6eabb6ddb7c53784792ee26b1e0657bde7eee7fb/ghc" 6eabb6d/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="6eabb6ddb7c53784792ee26b1e0657bde7eee7fb"
Allow recursive (undecidable) superclasses
This patch fulfils the request in Trac #11067, #10318, and #10592,
by lifting the conservative restrictions on superclass constraints.
These restrictions are there (and have been since Haskell was born) to
ensure that the transitive superclasses of a class constraint is a finite
set. However (a) this restriction is conservative, and can be annoying
when there really is no recursion, and (b) sometimes genuinely recursive
superclasses are useful (see the tickets).
Dimitrios and I worked out that there is actually a relatively simple way
to do the job. It’s described in some detail in
Note [The superclass story] in TcCanonical
Note [Expanding superclasses] in TcType
In brief, the idea is to expand superclasses only finitely, but to
iterate (using a loop that already existed) if there are more
superclasses to explore.
Other small things
- I improved grouping of error messages a bit in TcErrors
- I re-centred the haddock.compiler test, which was at 9.8%
above the norm, and which this patch pushed slightly over
}}}
--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10318#comment:9
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
