[GHC] #12364: Demand analysis for sum types

[GHC]

#12364: Demand analysis for sum types
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      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 jmct):

 Possibly, but GHC's much better about detecting recursiveness for product
 types, see the large section titled "Deciding which type constructors are
 recursive" in compiler/typecheck/TcTyDecls.hs. In particular there's this
 section:

 {{{
 The "recursive" flag for algebraic data types is irrelevant (never
 consulted)
 for types with more than one constructor.


 An algebraic data type M.T is "recursive" iff
         it has just one constructor, and
         (a) it is declared in an hi-boot file (see RdrHsSyn.hsIfaceDecl)
         (b) it is declared in a source file, but that source file has a
             companion hi-boot file which declares the type
  or     (c) one can get from its arg types to T via type synonyms,
             or by non-recursive newtypes or non-recursive product types in
 M
              e.g.  data T = MkT (T -> Int) Bool
 }}}

 I'm going to speculate wildly and say that it just hasn't been that
 important for GHC to detect recursiveness in sum types in the past, and
 therefore it just hasn't gotten very much attention. There probably
 shouldn't be a difference in theory, but GHC as it is today is better at
 avoiding recursiveness in product types and therefore would be better at
 avoiding the issue in that case. Though you're right in principle.

 Tomorrow morning I'll dig up my old notes and comment on #12368 giving an
 example. I don't want to confuse the two issues too much, though they're
 intimately related. #12368 is really about recursion in the _functions_
 though, which is an important distinction (and I definitely have examples
 where the current behavior of the 'cunning plan' is necessary).

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12364#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler