1. 04 May, 2010 1 commit
    • Ian Lynagh's avatar
      Fix build with GHC 6.10 · 63dde2e3
      Ian Lynagh authored
      In GHC 6.10, intersectionWith is (a -> b -> a) instead of (a -> b -> c),
      so we need to jump through some hoops to get the more general type.
      63dde2e3
  2. 03 May, 2010 1 commit
    • milan's avatar
      Replace FiniteMap and UniqFM with counterparts from containers. · 5ff8ce7f
      milan authored
      The original interfaces are kept. There is small performance improvement:
      - when compiling for five nofib, we get following speedups:
          Average                -----           -2.5%
          Average                -----           -0.6%
          Average                -----           -0.5%
          Average                -----           -5.5%
          Average                -----          -10.3%
      - when compiling HPC ten times, we get:
          switches                          oldmaps   newmaps
          -O -fasm                          117.402s  116.081s (98.87%)
          -O -fasm -fregs-graph             119.993s  118.735s (98.95%)
          -O -fasm -fregs-iterative         120.191s  118.607s (98.68%)
      5ff8ce7f
  3. 04 Dec, 2009 1 commit
  4. 24 Apr, 2009 1 commit
  5. 04 Sep, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      add assertion to check that UniqFM is only passed "positive" uniques · 8b7a0a10
      dias@eecs.harvard.edu authored
      The insertion code in UniqFM fails if a unique key
      produces a negative FastInt. I've added an assertion to check
      that each insertion uses a positive Unique.
      
      Where do the negative uniques come from? Both Simom M and
      I have run into this problem when computing hashes for data structures.
      In both cases, we have avoided the problem by ensuring that
      the hashes remain positive.
      8b7a0a10
  6. 31 Jul, 2008 1 commit
  7. 29 Mar, 2008 1 commit
  8. 25 Feb, 2008 1 commit
  9. 06 Feb, 2008 1 commit
  10. 03 Feb, 2008 2 commits
  11. 02 Feb, 2008 1 commit
  12. 17 Jan, 2008 1 commit
    • Isaac Dupree's avatar
      lots of portability changes (#1405) · 206b4dec
      Isaac Dupree authored
      re-recording to avoid new conflicts was too hard, so I just put it
      all in one big patch :-(  (besides, some of the changes depended on
      each other.)  Here are what the component patches were:
      
      Fri Dec 28 11:02:55 EST 2007  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * document BreakArray better
      
      Fri Dec 28 11:39:22 EST 2007  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * properly ifdef BreakArray for GHCI
      
      Fri Jan  4 13:50:41 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * change ifs on __GLASGOW_HASKELL__ to account for... (#1405)
        for it not being defined. I assume it being undefined implies
        a compiler with relatively modern libraries but without most
        unportable glasgow extensions.
      
      Fri Jan  4 14:21:21 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * MyEither-->EitherString to allow Haskell98 instance
      
      Fri Jan  4 16:13:29 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * re-portabilize Pretty, and corresponding changes
      
      Fri Jan  4 17:19:55 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * Augment FastTypes to be much more complete
      
      Fri Jan  4 20:14:19 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * use FastFunctions, cleanup FastString slightly
      
      Fri Jan  4 21:00:22 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * Massive de-"#", mostly Int# --> FastInt (#1405)
      
      Fri Jan  4 21:02:49 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * miscellaneous unnecessary-extension-removal
      
      Sat Jan  5 19:30:13 EST 2008  Isaac Dupree <id@isaac.cedarswampstudios.org>
        * add FastFunctions
      206b4dec
  13. 15 Sep, 2007 1 commit
  14. 05 Sep, 2007 1 commit
  15. 04 Sep, 2007 1 commit
  16. 03 Sep, 2007 1 commit
  17. 01 Sep, 2007 1 commit
  18. 06 Apr, 2007 1 commit
  19. 11 Oct, 2006 1 commit
  20. 05 Oct, 2006 1 commit
  21. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  22. 25 Jan, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Simon's big boxy-type commit · ac10f840
      simonpj@microsoft.com authored
      This very large commit adds impredicativity to GHC, plus
      numerous other small things.
        
      *** WARNING: I have compiled all the libraries, and
      ***	     a stage-2 compiler, and everything seems
      ***	     fine.  But don't grab this patch if you 
      ***	     can't tolerate a hiccup if something is
      ***	     broken.
        
      The big picture is this:
      
      a) GHC handles impredicative polymorphism, as described in the
         "Boxy types: type inference for higher-rank types and
         impredicativity" paper
      
      b) GHC handles GADTs in the new simplified (and very sligtly less
         epxrssive) way described in the
         "Simple unification-based type inference for GADTs" paper
      
        
      But there are lots of smaller changes, and since it was pre-Darcs
      they are not individually recorded.
        
      Some things to watch out for:
        
      c)   The story on lexically-scoped type variables has changed, as per
           my email.  I append the story below for completeness, but I 
           am still not happy with it, and it may change again.  In particular,
           the new story does not allow a pattern-bound scoped type variable
           to be wobbly, so (\(x::[a]) -> ...) is usually rejected.  This is
           more restrictive than before, and we might loosen up again.
        
      d)   A consequence of adding impredicativity is that GHC is a bit less
           gung ho about converting automatically between
        	(ty1 -> forall a. ty2)    and    (forall a. ty1 -> ty2)
           In particular, you may need to eta-expand some functions to make
           typechecking work again.
         
           Furthermore, functions are now invariant in their argument types,
           rather than being contravariant.  Again, the main consequence is
           that you may occasionally need to eta-expand function arguments when
           using higher-rank polymorphism.
        
      
      Please test, and let me know of any hiccups
      
      
      Scoped type variables in GHC
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      	January 2006
      
      0) Terminology.
         
         A *pattern binding* is of the form
      	pat = rhs
      
         A *function binding* is of the form
      	f pat1 .. patn = rhs
      
         A binding of the formm
      	var = rhs
         is treated as a (degenerate) *function binding*.
      
      
         A *declaration type signature* is a separate type signature for a
         let-bound or where-bound variable:
      	f :: Int -> Int
      
         A *pattern type signature* is a signature in a pattern: 
      	\(x::a) -> x
      	f (x::a) = x
      
         A *result type signature* is a signature on the result of a
         function definition:
      	f :: forall a. [a] -> a
      	head (x:xs) :: a = x
      
         The form
      	x :: a = rhs
         is treated as a (degnerate) function binding with a result
         type signature, not as a pattern binding.
      
      1) The main invariants:
      
           A) A lexically-scoped type variable always names a (rigid)
       	type variable (not an arbitrary type).  THIS IS A CHANGE.
              Previously, a scoped type variable named an arbitrary *type*.
      
           B) A type signature always describes a rigid type (since
      	its free (scoped) type variables name rigid type variables).
      	This is also a change, a consequence of (A).
      
           C) Distinct lexically-scoped type variables name distinct
      	rigid type variables.  This choice is open; 
      
      2) Scoping
      
      2(a) If a declaration type signature has an explicit forall, those type
         variables are brought into scope in the right hand side of the 
         corresponding binding (plus, for function bindings, the patterns on
         the LHS).  
      	f :: forall a. a -> [a]
      	f (x::a) = [x :: a, x]
         Both occurences of 'a' in the second line are bound by 
         the 'forall a' in the first line
      
         A declaration type signature *without* an explicit top-level forall
         is implicitly quantified over all the type variables that are
         mentioned in the type but not already in scope.  GHC's current
         rule is that this implicit quantification does *not* bring into scope
         any new scoped type variables.
      	f :: a -> a
      	f x = ...('a' is not in scope here)...
         This gives compatibility with Haskell 98
      
      2(b) A pattern type signature implicitly brings into scope any type
         variables mentioned in the type that are not already into scope.
         These are called *pattern-bound type variables*.
      	g :: a -> a -> [a]
      	g (x::a) (y::a) = [y :: a, x]
         The pattern type signature (x::a) brings 'a' into scope.
         The 'a' in the pattern (y::a) is bound, as is the occurrence on 
         the RHS.  
      
         A pattern type siganture is the only way you can bring existentials 
         into scope.
      	data T where
      	  MkT :: forall a. a -> (a->Int) -> T
      
      	f x = case x of
      		MkT (x::a) f -> f (x::a)
      
      2a) QUESTION
      	class C a where
      	  op :: forall b. b->a->a
      
      	instance C (T p q) where
      	  op = <rhs>
          Clearly p,q are in scope in <rhs>, but is 'b'?  Not at the moment.
          Nor can you add a type signature for op in the instance decl.
          You'd have to say this:
      	instance C (T p q) where
      	  op = let op' :: forall b. ...
      	           op' = <rhs>
      	       in op'
      
      3) A pattern-bound type variable is allowed only if the pattern's
         expected type is rigid.  Otherwise we don't know exactly *which*
         skolem the scoped type variable should be bound to, and that means
         we can't do GADT refinement.  This is invariant (A), and it is a 
         big change from the current situation.
      
      	f (x::a) = x	-- NO; pattern type is wobbly
      	
      	g1 :: b -> b
      	g1 (x::b) = x	-- YES, because the pattern type is rigid
      
      	g2 :: b -> b
      	g2 (x::c) = x	-- YES, same reason
      
      	h :: forall b. b -> b
      	h (x::b) = x	-- YES, but the inner b is bound
      
      	k :: forall b. b -> b
      	k (x::c) = x	-- NO, it can't be both b and c
      
      3a) You cannot give different names for the same type variable in the same scope
          (Invariant (C)):
      
      	f1 :: p -> p -> p		-- NO; because 'a' and 'b' would be
      	f1 (x::a) (y::b) = (x::a)	--     bound to the same type variable
      
      	f2 :: p -> p -> p		-- OK; 'a' is bound to the type variable
      	f2 (x::a) (y::a) = (x::a)	--     over which f2 is quantified
      					-- NB: 'p' is not lexically scoped
      
      	f3 :: forall p. p -> p -> p	-- NO: 'p' is now scoped, and is bound to
      	f3 (x::a) (y::a) = (x::a)	--     to the same type varialble as 'a'
      
      	f4 :: forall p. p -> p -> p	-- OK: 'p' is now scoped, and its occurences
      	f4 (x::p) (y::p) = (x::p)	--     in the patterns are bound by the forall
      
      
      3b) You can give a different name to the same type variable in different
          disjoint scopes, just as you can (if you want) give diferent names to 
          the same value parameter
      
      	g :: a -> Bool -> Maybe a
      	g (x::p) True  = Just x  :: Maybe p
      	g (y::q) False = Nothing :: Maybe q
      
      3c) Scoped type variables respect alpha renaming. For example, 
          function f2 from (3a) above could also be written:
      	f2' :: p -> p -> p
      	f2' (x::b) (y::b) = x::b
         where the scoped type variable is called 'b' instead of 'a'.
      
      
      4) Result type signatures obey the same rules as pattern types signatures.
         In particular, they can bind a type variable only if the result type is rigid
      
      	f x :: a = x	-- NO
      
      	g :: b -> b
      	g x :: b = x	-- YES; binds b in rhs
      
      5) A *pattern type signature* in a *pattern binding* cannot bind a 
         scoped type variable
      
      	(x::a, y) = ...		-- Legal only if 'a' is already in scope
      
         Reason: in type checking, the "expected type" of the LHS pattern is
         always wobbly, so we can't bind a rigid type variable.  (The exception
         would be for an existential type variable, but existentials are not
         allowed in pattern bindings either.)
       
         Even this is illegal
      	f :: forall a. a -> a
      	f x = let ((y::b)::a, z) = ... 
      	      in 
         Here it looks as if 'b' might get a rigid binding; but you can't bind
         it to the same skolem as a.
      
      6) Explicitly-forall'd type variables in the *declaration type signature(s)*
         for a *pattern binding* do not scope AT ALL.
      
      	x :: forall a. a->a	  -- NO; the forall a does 
      	Just (x::a->a) = Just id  --     not scope at all
      
      	y :: forall a. a->a
      	Just y = Just (id :: a->a)  -- NO; same reason
      
         THIS IS A CHANGE, but one I bet that very few people will notice.
         Here's why:
      
      	strange :: forall b. (b->b,b->b)
      	strange = (id,id)
      
      	x1 :: forall a. a->a
      	y1 :: forall b. b->b
      	(x1,y1) = strange
      
          This is legal Haskell 98 (modulo the forall). If both 'a' and 'b'
          both scoped over the RHS, they'd get unified and so cannot stand
          for distinct type variables. One could *imagine* allowing this:
         
      	x2 :: forall a. a->a
      	y2 :: forall a. a->a
      	(x2,y2) = strange
      
          using the very same type variable 'a' in both signatures, so that
          a single 'a' scopes over the RHS.  That seems defensible, but odd,
          because though there are two type signatures, they introduce just
          *one* scoped type variable, a.
      
      7) Possible extension.  We might consider allowing
      	\(x :: [ _ ]) -> <expr>
          where "_" is a wild card, to mean "x has type list of something", without
          naming the something.
      ac10f840
  23. 09 Aug, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-08-09 13:21:13 by simonmar] · fe1f6b03
      simonmar authored
      mapUFM was strict in the structure of the tree, perhaps accidentally.
      In any case, this interacted badly with the use of mapVarEnv in
      SimplEnv.mkCoreSubst, which assumed that the map was lazy.
      
      mapUFM is now lazy in the structure of the tree, which matches the
      behaviour of FiniteMap.mapFM.
      
      This fixes some long compilation times, in particular HTMLMonad98.hs
      from WASH used to take 2 mins to compile without optimisation, now
      takes less than 20 seconds.
      fe1f6b03
  24. 19 Jul, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-07-19 16:44:50 by simonpj] · a7ecdf96
      simonpj authored
      WARNING: this is a big commit.  You might want 
      	to wait a few days before updating, in case I've 
      	broken something.
      
      	However, if any of the changes are what you wanted,
      	please check it out and test!
      
      This commit does three main things:
      
      1. A re-organisation of the way that GHC handles bindings in HsSyn.
         This has been a bit of a mess for quite a while.  The key new
         types are
      
      	-- Bindings for a let or where clause
      	data HsLocalBinds id
      	  = HsValBinds (HsValBinds id)
      	  | HsIPBinds  (HsIPBinds id)
      	  | EmptyLocalBinds
      
      	-- Value bindings (not implicit parameters)
      	data HsValBinds id
      	  = ValBindsIn  -- Before typechecking
      		(LHsBinds id) [LSig id]	-- Not dependency analysed
      					-- Recursive by default
      
      	  | ValBindsOut	-- After typechecking
      		[(RecFlag, LHsBinds id)]-- Dependency analysed
      
      2. Implement Mark Jones's idea of increasing polymoprhism
         by using type signatures to cut the strongly-connected components
         of a recursive group.  As a consequence, GHC no longer insists
         on the contexts of the type signatures of a recursive group
         being identical.
      
         This drove a significant change: the renamer no longer does dependency
         analysis.  Instead, it attaches a free-variable set to each binding,
         so that the type checker can do the dep anal.  Reason: the typechecker
         needs to do *two* analyses:
      	one to find the true mutually-recursive groups
      		(which we need so we can build the right CoreSyn)
      	one to find the groups in which to typecheck, taking
      		account of type signatures
      
      3. Implement non-ground SPECIALISE pragmas, as promised, and as
         requested by Remi and Ross.  Certainly, this should fix the 
         current problem with GHC, namely that if you have
      	g :: Eq a => a -> b -> b
         then you can now specialise thus
      	SPECIALISE g :: Int -> b -> b
          (This didn't use to work.)
      
         However, it goes further than that.  For example:
      	f :: (Eq a, Ix b) => a -> b -> b
         then you can make a partial specialisation
      	SPECIALISE f :: (Eq a) => a -> Int -> Int
      
          In principle, you can specialise f to *any* type that is
          "less polymorphic" (in the sense of subsumption) than f's 
          actual type.  Such as
      	SPECIALISE f :: Eq a => [a] -> Int -> Int
          But I haven't tested that.
      
          I implemented this by doing the specialisation in the typechecker
          and desugarer, rather than leaving around the strange SpecPragmaIds,
          for the specialiser to find.  Indeed, SpecPragmaIds have vanished 
          altogether (hooray).
      
          Pragmas in general are handled more tidily.  There's a new
          data type HsBinds.Prag, which lives in an AbsBinds, and carries
          pragma info from the typechecker to the desugarer.
      
      
      Smaller things
      
      - The loop in the renamer goes via RnExpr, instead of RnSource.
        (That makes it more like the type checker.)
      
      - I fixed the thing that was causing 'check_tc' warnings to be 
        emitted.
      a7ecdf96
  25. 31 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-31 10:16:33 by simonmar] · 853e20a3
      simonmar authored
      Tweaks to get the GHC sources through Haddock.  Doesn't quite work
      yet, because Haddock complains about the recursive modules.  Haddock
      needs to understand SOURCE imports (it can probably just ignore them
      as a first attempt).
      853e20a3
  26. 30 Sep, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-09-30 10:35:15 by simonpj] · 23f40f0e
      simonpj authored
      ------------------------------------
      	Add Generalised Algebraic Data Types
      	------------------------------------
      
      This rather big commit adds support for GADTs.  For example,
      
          data Term a where
       	  Lit :: Int -> Term Int
      	  App :: Term (a->b) -> Term a -> Term b
      	  If  :: Term Bool -> Term a -> Term a
      	  ..etc..
      
          eval :: Term a -> a
          eval (Lit i) = i
          eval (App a b) = eval a (eval b)
          eval (If p q r) | eval p    = eval q
          		    | otherwise = eval r
      
      
      Lots and lots of of related changes throughout the compiler to make
      this fit nicely.
      
      One important change, only loosely related to GADTs, is that skolem
      constants in the typechecker are genuinely immutable and constant, so
      we often get better error messages from the type checker.  See
      TcType.TcTyVarDetails.
      
      There's a new module types/Unify.lhs, which has purely-functional
      unification and matching for Type. This is used both in the typechecker
      (for type refinement of GADTs) and in Core Lint (also for type refinement).
      23f40f0e
  27. 16 Aug, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-08-16 09:53:47 by simonpj] · 4e325538
      simonpj authored
      -------------------------------
      	Add instance information to :i
       	Get rid of the DeclPool
      	-------------------------------
      
      
      1.  Add instance information to :info command.  GHCi now prints out
          which instances a type or class belongs to, when you use :i
      
      2.  Tidy up printing of unqualified names in user output.
          Previously Outputable.PrintUnqualified was
      	type PrintUnqualified = Name -> Bool
          but it's now
      	type PrintUnqualified = ModuleName -> OccName -> Bool
          This turns out to be tidier even for Names, and it's now also usable
          when printing IfaceSyn stuff in GHCi, eliminating a grevious hack.
      
      3.  On the way to doing this, Simon M had the great idea that we could
          get rid of the DeclPool holding pen, which held declarations read from
          interface files but not yet type-checked.   We do this by eagerly
          populating the TypeEnv with thunks what, when poked, do the type
          checking.   This is just a logical continuation of lazy import
          mechanism we've now had for some while.
      
      The InstPool and RulePool still exist, but I plan to get rid of them in
      the same way.  The new scheme does mean that more rules get sucked in than
      before, because previously the TypeEnv was used to mean "this thing was needed"
      and hence to control which rules were sucked in.  But now the TypeEnv is
      populated more eagerly => more rules get sucked in.  However this problem
      will go away when I get rid of the Inst and Rule pools.
      
      I should have kept these changes separate, but I didn't.  Change (1)
      affects mainly
      	TcRnDriver, HscMain, CompMan, InteractiveUI
      whereas change (3) is more wide ranging.
      4e325538
  28. 06 Nov, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-11-06 17:09:50 by simonpj] · 1f5e5580
      simonpj authored
      ------------------------------------
      	Major increment for Template Haskell
      	------------------------------------
      
      1.  New abstract data type "Name" which appears where String used to be.
          E.g. 	data Exp = VarE Name | ...
      
      2.  New syntax 'x and ''T, for quoting Names.  It's rather like [| x |]
          and [t| T |] respectively, except that
      
      	a) it's non-monadic:  'x :: Name
      	b) you get a Name not an Exp or Type
      
      3.  reify is an ordinary function
      	reify :: Name -> Q Info
          New data type Info which tells what TH knows about Name
      
      4.  Local variables work properly.  So this works now (crashed before):
      	f x = $( [| x |] )
      
      5.  THSyntax is split up into three modules:
      
        Language.Haskell.TH		TH "clients" import this
      
        Language.Haskell.TH.THSyntax	data type declarations and internal stuff
      
        Language.Haskell.TH.THLib	Support library code (all re-exported
      				by TH), including smart constructors and
      				pretty printer
      
      6.  Error reporting and recovery are in (not yet well tested)
      
      	report :: Bool {- True <=> fatal -} -> String -> Q ()
      	recover :: Q a -> Q a -> Q a
      
      7.  Can find current module
      
      	currentModule :: Q String
      
      
      Much other cleaning up, needless to say.
      1f5e5580
  29. 03 Jun, 2003 1 commit
  30. 29 Aug, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-08-29 15:44:11 by simonmar] · ce9687a5
      simonmar authored
      Housekeeping:
      
        - The main goal is to remove dependencies on hslibs for a
          bootstrapped compiler, leaving only a requirement that the
          packages base, haskell98 and readline are built in stage 1 in
          order to bootstrap.  We're almost there: Posix is still required
          for signal handling, but all other dependencies on hslibs are now
          gone.
      
          Uses of Addr and ByteArray/MutableByteArray array are all gone
          from the compiler.  PrimPacked defines the Ptr type for GHC 4.08
          (which didn't have it), and it defines simple BA and MBA types to
          replace uses of ByteArray and MutableByteArray respectively.
      
        - Clean up import lists.  HsVersions.h now defines macros for some
          modules which have moved between GHC versions.  eg. one now
          imports 'GLAEXTS' to get at unboxed types and primops in the
          compiler.
      
          Many import lists have been sorted as per the recommendations in
          the new style guidelines in the commentary.
      
      I've built the compiler with GHC 4.08.2, 5.00.2, 5.02.3, 5.04 and
      itself, and everything still works here.  Doubtless I've got something
      wrong, though.
      ce9687a5
  31. 27 May, 2002 1 commit
  32. 05 Feb, 2002 1 commit
    • keithw's avatar
      [project @ 2002-02-05 16:44:37 by keithw] · 6eaccd1a
      keithw authored
      Generalise types of minusUFM and intersectUFM_C (this was applied long
      ago to FiniteMap, IIRC).
      
      Untested: I haven't got a build tree handy, so please shoot me if this
      2-line change to two type signatures is type-incorrect.  Sorry!
      6eaccd1a
  33. 11 Dec, 2001 1 commit
  34. 17 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-17 15:28:30 by simonpj] · fdc83001
      simonpj authored
      --------------------------------
      	First cut at the demand analyser
      	--------------------------------
      
      This demand analyser is intended to replace the strictness/absence
      analyser, and the CPR analyser.
      
      This commit adds it to the compiler, but in an entirely non-invasive
      way.
      
      	If you build the compiler without -DDEBUG,
      	you won't get it at all.
      
      	If you build the compiler with -DDEBUG,
      	you'll get the demand analyser, but the existing
      	strictness analyser etc are still there.  All the
      	demand analyser does is to compare its output with
      	the existing stuff and report differences.
      
      There's no cross-module stuff for demand info yet.
      
      The strictness/demand info is put the IdInfo as
      	newStrictnessInfo
      	newDemandInfo
      
      Eventually we'll remove the old ones.
      
      Simon
      fdc83001
  35. 12 Oct, 2000 1 commit
    • simonmar's avatar
      [project @ 2000-10-12 13:11:45 by simonmar] · 30d55993
      simonmar authored
      Move FAST_INT and FAST_BOOL into their own module FastTypes, replacing
      the macro definitions in HsVersions.h with real definitions.  Change
      most of the names in the process.
      
      Now we don't get bogus imports of GlaExts all over the place, and
      -fwarn-unused-imports is less noisy.
      30d55993
  36. 03 Dec, 1999 1 commit
    • lewie's avatar
      [project @ 1999-12-03 18:17:29 by lewie] · c2b053f3
      lewie authored
      Extend getTyVarsToGen to take the closure of the set of tyvars
      with respect to functional dependencies.  Really simple programs
      using functional dependencies work now.  Also fixed a small glitch
      where trivial (empty) FunDeps were being tossed into the context willy nilly.
      c2b053f3
  37. 22 Jun, 1999 1 commit
  38. 26 May, 1999 1 commit
  39. 18 Dec, 1998 1 commit
    • simonpj's avatar
      [project @ 1998-12-18 17:40:31 by simonpj] · 7e602b0a
      simonpj authored
      Another big commit from Simon.  Actually, the last one
      didn't all go into the main trunk; because of a CVS glitch it
      ended up in the wrong branch.
      
      So this commit includes:
      
      * Scoped type variables
      * Warnings for unused variables should work now (they didn't before)
      * Simplifier improvements:
      	- Much better treatment of strict arguments
      	- Better treatment of bottoming Ids
      	- No need for w/w split for fns that are merely strict
      	- Fewer iterations needed, I hope
      * Less gratuitous renaming in interface files and abs C
      * OccName is a separate module, and is an abstract data type
      
      I think the whole Prelude and Exts libraries compile correctly.
      Something isn't quite right about typechecking existentials though.
      7e602b0a