[project @ 1999-07-14 14:40:20 by simonpj]

Main things:

* Add splitProductType_maybe to DataCon.lhs, with type
  splitProductType_maybe
	:: Type 			-- A product type, perhaps
	-> Maybe (TyCon, 		-- The type constructor
		  [Type],		-- Type args of the tycon
		  DataCon,		-- The data constructor
		  [Type])		-- Its *representation* arg types

  Then use it in many places (e.g. worker-wrapper places) instead
  of a pile of junk

* Clean up various uses of dataConArgTys, which were plain wrong because
  they weren't passed the existential type arguments.  Most of these calls
  are eliminated by using splitProductType_maybe above.  I hope I correctly
  squashed the others. This fixes a bug that Meurig's programs showed up.

    module FailGHC (killSustainer) where
    import Weak
    import IOExts

    data Sustainer = forall a . Sustainer (IORef (Maybe a)) (IO ())

    killSustainer :: Sustainer -> IO ()
    killSustainer (Sustainer _ act) = act

  The above program used to kill the compiler.

* A fairly concerted attack on the Dreaded Space Leak.
	- Add Type.seqType, CoreSyn.seqExpr, CoreSyn.seqRules

	- Add some seq'ing when building Ids and IdInfos
		These reduce the space usage a lot

	- Add CoreSyn.coreBindsSize, which is pretty strict in the program,
		and call it when we have -dshow-passes.

	- Do not put the inlining in an Id that is being plugged into
		the result-expression of the simplifier.  This cures
		a the 'wedge' in the space profile for reasons I don't understand fully

  Together, these things reduce the max space usage when compiling PrelNum from
  17M to about 7Mbytes.

  I think there are now *too many* seqs, and they waste work, but I don't have
  time to find which ones.

  Furthermore, we aren't done. For some reason, some of the stuff allocated by
  the simplifier makes it through all during code generation and I don't see why.
  There's a should-be-unnecessary call to coreBindsSize in Main.main which
  zaps some, but not all of this space.

  -dshow-passes reduces space usage a bit, but I don't think it should really.

  All the measurements were made on a compiler compiled with profiling by
  GHC 3.03.    I hope they carry over to other builds!

* One trivial thing: changed all variables 'label' to 'lbl', becuase the
  former is a keyword with -fglagow-exts in GHC 3.03 (which I was compiling with).
  Something similar in StringBuffer.