1. 20 Feb, 2003 1 commit
  2. 12 Feb, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-02-12 15:01:31 by simonpj] · 42b63073
      simonpj authored
      -------------------------------------
        Big upheaval to the way that constructors are named
      	-------------------------------------
      
      This commit enshrines the new story for constructor names.  We could never
      really get External Core to work nicely before, but now it does.
      
      The story is laid out in detail in the Commentary
      	ghc/docs/comm/the-beast/data-types.html
      so I will not repeat it here.
      
      	[Manuel: the commentary isn't being updated, apparently.]
      
      However, the net effect is that in Core and in External Core, contructors look
      like constructors, and the way things are printed is all consistent.
      
      It is a fairly pervasive change (which is why it has been so long postponed),
      but I hope the question is now finally closed.
      
      All the libraries compile etc, and I've run many tests, but doubtless there will
      be some dark corners.
      42b63073
  3. 04 Feb, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-02-04 15:09:38 by simonpj] · 957bf375
      simonpj authored
      -------------------------------------
      	Remove all vestiges of usage analysis
      	-------------------------------------
      
      This commit removes a large blob of usage-analysis-related code, almost
      all of which was commented out.
      
      Sadly, it doesn't look as if Keith is going to have enough time to polish it
      up, and in any case the actual performance benefits (so far as we can measure
      them) turned out to be pretty modest (a few percent).
      
      So, with regret, I'm chopping it all out.  It's still there in the repository
      if anyone wants go hack on it.  And Tobias Gedell at Chalmers is implementing
      a different analysis, via External Core.
      957bf375
  4. 23 Jan, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-01-23 16:01:33 by simonmar] · 6873f3d4
      simonmar authored
      Allow FFI declarations to have polymorphic types. eg:
      
      foreign import ccall unsafe "stdlib.h &free" pFree :: FunPtr (Ptr a -> IO ())
      
      (the change actually removed a line, the extra lines are because I
      reformatted an import declaration).
      6873f3d4
  5. 11 Nov, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-11-11 10:53:28 by simonpj] · 0adb7175
      simonpj authored
      ------------------
        	   Fix a newtype-deriving bug
      		------------------
      
      The new newtype-deriving mechanism was erroneously using the
      *representation type* of the newtype.  The rep type looks through all
      ihtermediate newtypes, so that is wrong.  See Note [newtype
      representation] in TcDeriv.lhs
      
      deriving/should_run/drvrun013 now tests for this.
      0adb7175
  6. 13 Sep, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-09-13 15:02:25 by simonpj] · 9af77fa4
      simonpj authored
      --------------------------------------
      	Make Template Haskell into the HEAD
      	--------------------------------------
      
      This massive commit transfers to the HEAD all the stuff that
      Simon and Tim have been doing on Template Haskell.  The
      meta-haskell-branch is no more!
      
      WARNING: make sure that you
      
        * Update your links if you are using link trees.
          Some modules have been added, some have gone away.
      
        * Do 'make clean' in all library trees.
          The interface file format has changed, and you can
          get strange panics (sadly) if GHC tries to read old interface files:
          e.g.  ghc-5.05: panic! (the `impossible' happened, GHC version 5.05):
      	  Binary.get(TyClDecl): ForeignType
      
        * You need to recompile the rts too; Linker.c has changed
      
      
      However the libraries are almost unaltered; just a tiny change in
      Base, and to the exports in Prelude.
      
      
      NOTE: so far as TH itself is concerned, expression splices work
      fine, but declaration splices are not complete.
      
      
      		---------------
      		The main change
      		---------------
      
      The main structural change: renaming and typechecking have to be
      interleaved, because we can't rename stuff after a declaration splice
      until after we've typechecked the stuff before (and the splice
      itself).
      
      * Combine the renamer and typecheker monads into one
      	(TcRnMonad, TcRnTypes)
        These two replace TcMonad and RnMonad
      
      * Give them a single 'driver' (TcRnDriver).  This driver
        replaces TcModule.lhs and Rename.lhs
      
      * The haskell-src library package has a module
      	Language/Haskell/THSyntax
        which defines the Haskell data type seen by the TH programmer.
      
      * New modules:
      	hsSyn/Convert.hs 	converts THSyntax -> HsSyn
      	deSugar/DsMeta.hs 	converts HsSyn -> THSyntax
      
      * New module typecheck/TcSplice type-checks Template Haskell splices.
      
      		-------------
      		Linking stuff
      		-------------
      
      * ByteCodeLink has been split into
      	ByteCodeLink	(which links)
      	ByteCodeAsm	(which assembles)
      
      * New module ghci/ObjLink is the object-code linker.
      
      * compMan/CmLink is removed entirely (was out of place)
        Ditto CmTypes (which was tiny)
      
      * Linker.c initialises the linker when it is first used (no need to call
        initLinker any more).  Template Haskell makes it harder to know when
        and whether to initialise the linker.
      
      
      	-------------------------------------
      	Gathering the LIE in the type checker
      	-------------------------------------
      
      * Instead of explicitly gathering constraints in the LIE
      	tcExpr :: RenamedExpr -> TcM (TypecheckedExpr, LIE)
        we now dump the constraints into a mutable varabiable carried
        by the monad, so we get
      	tcExpr :: RenamedExpr -> TcM TypecheckedExpr
      
        Much less clutter in the code, and more efficient too.
        (Originally suggested by Mark Shields.)
      
      
      		-----------------
      		Remove "SysNames"
      		-----------------
      
      Because the renamer and the type checker were entirely separate,
      we had to carry some rather tiresome implicit binders (or "SysNames")
      along inside some of the HsDecl data structures.  They were both
      tiresome and fragile.
      
      Now that the typechecker and renamer are more intimately coupled,
      we can eliminate SysNames (well, mostly... default methods still
      carry something similar).
      
      		-------------
      		Clean up HsPat
      		-------------
      
      One big clean up is this: instead of having two HsPat types (InPat and
      OutPat), they are now combined into one.  This is more consistent with
      the way that HsExpr etc is handled; there are some 'Out' constructors
      for the type checker output.
      
      So:
      	HsPat.InPat	--> HsPat.Pat
      	HsPat.OutPat	--> HsPat.Pat
      	No 'pat' type parameter in HsExpr, HsBinds, etc
      
      	Constructor patterns are nicer now: they use
      		HsPat.HsConDetails
      	for the three cases of constructor patterns:
      		prefix, infix, and record-bindings
      
      	The *same* data type HsConDetails is used in the type
      	declaration of the data type (HsDecls.TyData)
      
      Lots of associated clean-up operations here and there.  Less code.
      Everything is wonderful.
      9af77fa4
  7. 06 Sep, 2002 2 commits
  8. 29 Jul, 2002 1 commit
  9. 20 Jun, 2002 1 commit
  10. 22 Apr, 2002 1 commit
  11. 25 Mar, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-03-25 15:08:38 by simonpj] · aaed1181
      simonpj authored
      -------------------------------
      	Fix bugs in rank-N polymorphism
      	-------------------------------
      
      Discussion with Mark showed up some bugs in the rank-N
      polymorphism stuff, especally concerning the treatment of
      'hole' type variables.
      
      See especially TcMType:
      	newHoleTyVar
      	readHoleResult
      	zapToType
      
      Also the treatment of conditionals and case branches
      is done right now, using zapToType
      aaed1181
  12. 14 Mar, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-03-14 15:27:15 by simonpj] · 1553c778
      simonpj authored
      ------------------------
      	Change
      		GlobalName --> ExternalName
      		LocalName  ->  InternalName
      	------------------------
      
      For a long time there's been terminological confusion between
      
      	GlobalName vs LocalName	 (property of a Name)
      	GlobalId vs LocalId	 (property of an Id)
      
      I've now changed the terminology for Name to be
      
      	ExternalName vs InternalName
      
      I've also added quite a bit of documentation in the Commentary.
      1553c778
  13. 12 Mar, 2002 2 commits
    • simonpj's avatar
      [project @ 2002-03-12 15:55:26 by simonpj] · 72c2f581
      simonpj authored
      ------------------------
      	Fix a type-invariant bug
      	------------------------
      
      We need to call Type.mkGenTyConApp from Type.mkAppTy, in
      case there's a partially applied type synonym.  Explanation
      with Type.mkAppTy.  All part of GHC's rather liberal treatment
      of type synonyms.
      
      Shown up by a program from Ralf Laemmel:
      
      	type Generic i o = forall x. i x -> o x
      	type Id x = x
      	comb :: Generic Id Id
      
      Test is typecheck/should_compile/tc149.hs
      72c2f581
    • simonpj's avatar
      [project @ 2002-03-12 09:12:57 by simonpj] · 49c84dec
      simonpj authored
      Comments
      49c84dec
  14. 08 Mar, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-03-08 15:50:53 by simonpj] · a170160c
      simonpj authored
      --------------------------------------
      	Lift the class-method type restriction
      	--------------------------------------
      
      Haskell 98 prohibits class method types to mention constraints on the
      class type variable, thus:
      
        class Seq s a where
          fromList :: [a] -> s a
          elem     :: Eq a => a -> s a -> Bool
      
      The type of 'elem' is illegal in Haskell 98, because it contains the
      constraint 'Eq a', which constrains only the class type variable (in
      this case 'a').
      
      This commit lifts the restriction.  The way we do that is to do a full
      context reduction (tcSimplifyCheck) step for each method separately in
      TcClassDcl.tcMethodBind, rather than doing a single context reduction
      for the whole group of method bindings.
      
      As a result, I had to reorganise the code a bit, and tidy up.
      a170160c
  15. 28 Feb, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-02-28 12:17:19 by simonpj] · 469c3333
      simonpj authored
      ---------------------------------
      	Fix a rather obscure bug in tcGen
      	---------------------------------
      
      This bug concerns deciding when a type variable "escapes",
      and hence we can't generalise it.  Our new subsumption-checking
      machinery for higher-ranked types requires a slightly
      more general approach than I had before.  The main excitement
      is in TcUnify.checkSigTyVars and its friends.
      
      As usual, I moved functions around and cleaned things up a bit;
      hence the multi-module commit.
      469c3333
  16. 13 Feb, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-02-13 15:14:06 by simonpj] · e7030995
      simonpj authored
      --------------------------------------------
      	Fix a bugs in type inference for rank-N types
      	--------------------------------------------
      
      We discovered this bug when looking at type rules!
      
      1. When type checking (e :: sigma-ty), we must specialise sigma-ty,
         else we lose the invariant that tcMonoType has.
      
      2. In tcExpr_id, we should pass in a Hole tyvar not an ordinary tyvar.
      
      As usual, I moved some functions around in consequence.
      e7030995
  17. 07 Feb, 2002 2 commits
    • simonpj's avatar
      [project @ 2002-02-07 14:06:00 by simonpj] · ad552fe2
      simonpj authored
      -------------------------------------------
      	Improve the "stragely-kinded tyvar" problem
      	-------------------------------------------
      
      When the type checker finds a type variable with no binding,
      which means it can be instantiated with an arbitrary type, it
      usually instantiates it to Void.  Eg.
      
      	length []
      ===>
      	length Void (Nil Void)
      
      But in really obscure programs, the type variable might have
      a kind other than *, so we need to invent a suitably-kinded type.
      
      This commit uses
      	Void for kind *
      	List for kind *->*
      	Tuple for kind *->...*->*
      
      which deals with most cases.  (Previously, it only dealt with
      kind *.)
      
      In the other cases, it just makes up a TyCon with a suitable
      kind.  If this gets into an interface file, anyone reading that
      file won't understand it.  This is fixable (by making the client
      of the interface file make up a TyCon too) but it is tiresome and
      never happens, so I am leaving it.
      
      Most of the added lines are comments.
      ad552fe2
    • simonpj's avatar
      [project @ 2002-02-07 12:51:34 by simonpj] · 20f50b2a
      simonpj authored
      ----------------------------------------------------
      	Make TcType.match and TcUnify.uUnboundVar kind-aware
      	----------------------------------------------------
      
      George Russel had apparently-overlapping (ha) instance decls like
      
      	instance .. => C (a b) where
      	instance .. => C (x y) where
      
      But the a,b and x,y were different kinds!  Turned out that TcType.unify
      was kind-aware (so we didn't report a duplicate instance decl, but TcType.match
      was not (so we simply selected the wrong one, and got a mis-kinded constraint
      popping up from the ".."  part.  Very exciting to track down.
      
      I also make the ordinary unification kind-aware in the same way.  It's
      quite legitimate to attempt to unify, say,
      	(a b)    with     (c d)
      but the unification should fail if a's kind differs from c's.
      (There was a kind of debug warning before, but it's actually not an error
      in the compiler... so it should just make unification fail gracefully.)
      20f50b2a
  18. 06 Feb, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-02-06 15:54:23 by simonpj] · 979947f5
      simonpj authored
      Eliminate all vestiages of UsageTy, in preparation for
      	Keith's new version.  Hurrah!
      
      	Keith: LBVarInfo and usOnce,usMany are still there,
      	because I know you have eliminated LBVarInfo, and I didn't
      	want to cause unnecessary conflicts.
      979947f5
  19. 04 Feb, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-02-04 11:59:55 by simonpj] · 18dbe364
      simonpj authored
      -----------------------------
      	Improve type validity checking
      	-----------------------------
      
      Two main effects here
      
      a) Type synonyms can be unboxed tuples
      	tupe T = (# Int, Int #)
      
      	f :: Int -> T
      
      b) Hoisting works for implicit parameters
      
      	f :: Int -> (?x::Int) => Int
      18dbe364
  20. 21 Dec, 2001 1 commit
  21. 29 Nov, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-11-29 13:47:09 by simonpj] · 32a89583
      simonpj authored
      ------------------------------
      	Add linear implicit parameters
      	------------------------------
      
      Linear implicit parameters are an idea developed by Koen Claessen,
      Mark Shields, and Simon PJ, last week.  They address the long-standing
      problem that monads seem over-kill for certain sorts of problem, notably:
      
      	* distributing a supply of unique names
      	* distributing a suppply of random numbers
      	* distributing an oracle (as in QuickCheck)
      
      
      Linear implicit parameters are just like ordinary implicit parameters,
      except that they are "linear" -- that is, they cannot be copied, and
      must be explicitly "split" instead.  Linear implicit parameters are
      written '%x' instead of '?x'.  (The '/' in the '%' suggests the
      split!)
      
      For example:
      
          data NameSupply = ...
      
          splitNS :: NameSupply -> (NameSupply, NameSupply)
          newName :: NameSupply -> Name
      
          instance PrelSplit.Splittable NameSupply where
      	split = splitNS
      
      
          f :: (%ns :: NameSupply) => Env -> Expr -> Expr
          f env (Lam x e) = Lam x' (f env e)
      		    where
      		      x'   = newName %ns
      		      env' = extend env x x'
          ...more equations for f...
      
      Notice that the implicit parameter %ns is consumed
      	once by the call to newName
      	once by the recursive call to f
      
      So the translation done by the type checker makes
      the parameter explicit:
      
          f :: NameSupply -> Env -> Expr -> Expr
          f ns env (Lam x e) = Lam x' (f ns1 env e)
      		       where
      	 		 (ns1,ns2) = splitNS ns
      			 x' = newName ns2
      			 env = extend env x x'
      
      Notice the call to 'split' introduced by the type checker.
      How did it know to use 'splitNS'?  Because what it really did
      was to introduce a call to the overloaded function 'split',
      ndefined by
      
      	class Splittable a where
      	  split :: a -> (a,a)
      
      The instance for Splittable NameSupply tells GHC how to implement
      split for name supplies.  But we can simply write
      
      	g x = (x, %ns, %ns)
      
      and GHC will infer
      
      	g :: (Splittable a, %ns :: a) => b -> (b,a,a)
      
      The Splittable class is built into GHC.  It's defined in PrelSplit,
      and exported by GlaExts.
      
      Other points:
      
      * '?x' and '%x' are entirely distinct implicit parameters: you
        can use them together and they won't intefere with each other.
      
      * You can bind linear implicit parameters in 'with' clauses.
      
      * You cannot have implicit parameters (whether linear or not)
        in the context of a class or instance declaration.
      
      
      Warnings
      ~~~~~~~~
      The monomorphism restriction is even more important than usual.
      Consider the example above:
      
          f :: (%ns :: NameSupply) => Env -> Expr -> Expr
          f env (Lam x e) = Lam x' (f env e)
      		    where
      		      x'   = newName %ns
      		      env' = extend env x x'
      
      If we replaced the two occurrences of x' by (newName %ns), which is
      usually a harmless thing to do, we get:
      
          f :: (%ns :: NameSupply) => Env -> Expr -> Expr
          f env (Lam x e) = Lam (newName %ns) (f env e)
      		    where
      		      env' = extend env x (newName %ns)
      
      But now the name supply is consumed in *three* places
      (the two calls to newName,and the recursive call to f), so
      the result is utterly different.  Urk!  We don't even have
      the beta rule.
      
      Well, this is an experimental change.  With implicit
      parameters we have already lost beta reduction anyway, and
      (as John Launchbury puts it) we can't sensibly reason about
      Haskell programs without knowing their typing.
      
      Of course, none of this is throughly tested, either.
      32a89583
  22. 26 Nov, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-11-26 09:20:25 by simonpj] · 5e3f005d
      simonpj authored
      ----------------------
      	Implement Rank-N types
      	----------------------
      
      This commit implements the full glory of Rank-N types, using
      the Odersky/Laufer approach described in their paper
      	"Putting type annotations to work"
      
      In fact, I've had to adapt their approach to deal with the
      full glory of Haskell (including pattern matching, and the
      scoped-type-variable extension).  However, the result is:
      
      * There is no restriction to rank-2 types.  You can nest forall's
        as deep as you like in a type.  For example, you can write a type
        like
      	p :: ((forall a. Eq a => a->a) -> Int) -> Int
        This is a rank-3 type, illegal in GHC 5.02
      
      * When matching types, GHC uses the cunning Odersky/Laufer coercion
        rules.  For example, suppose we have
      	q :: (forall c. Ord c => c->c) -> Int
        Then, is this well typed?
      	x :: Int
      	x = p q
        Yes, it is, but GHC has to generate the right coercion.  Here's
        what it looks like with all the big lambdas and dictionaries put in:
      
      	x = p (\ f :: (forall a. Eq a => a->a) ->
      		 q (/\c \d::Ord c -> f c (eqFromOrd d)))
      
        where eqFromOrd selects the Eq superclass dictionary from the Ord
        dicationary:		eqFromOrd :: Ord a -> Eq a
      
      
      * You can use polymorphic types in pattern type signatures.  For
        example:
      
      	f (g :: forall a. a->a) = (g 'c', g True)
      
        (Previously, pattern type signatures had to be monotypes.)
      
      * The basic rule for using rank-N types is that you must specify
        a type signature for every binder that you want to have a type
        scheme (as opposed to a plain monotype) as its type.
      
        However, you don't need to give the type signature on the
        binder (as I did above in the defn for f).  You can give it
        in a separate type signature, thus:
      
      	f :: (forall a. a->a) -> (Char,Bool)
      	f g = (g 'c', g True)
      
        GHC will push the external type signature inwards, and use
        that information to decorate the binders as it comes across them.
        I don't have a *precise* specification of this process, but I
        think it is obvious enough in practice.
      
      * In a type synonym you can use rank-N types too.  For example,
        you can write
      
      	type IdFun = forall a. a->a
      
      	f :: IdFun -> (Char,Bool)
      	f g = (g 'c', g True)
      
        As always, type synonyms must always occur saturated; GHC
        expands them before it does anything else.  (Still, GHC goes
        to some trouble to keep them unexpanded in error message.)
      
      
      The main plan is as before.  The main typechecker for expressions,
      tcExpr, takes an "expected type" as its argument.  This greatly
      improves error messages.  The new feature is that when this
      "expected type" (going down) meets an "actual type" (coming up)
      we use the new subsumption function
      	TcUnify.tcSub
      which checks that the actual type can be coerced into the
      expected type (and produces a coercion function to demonstrate).
      
      The main new chunk of code is TcUnify.tcSub.  The unifier itself
      is unchanged, but it has moved from TcMType into TcUnify.  Also
      checkSigTyVars has moved from TcMonoType into TcUnify.
      Result: the new module, TcUnify, contains all stuff relevant
      to subsumption and unification.
      
      Unfortunately, there is now an inevitable loop between TcUnify
      and TcSimplify, but that's just too bad (a simple TcUnify.hi-boot
      file).
      
      
      All of this doesn't come entirely for free.  Here's the typechecker
      line count (INCLUDING comments)
      	Before	16,551
      	After	17,116
      5e3f005d
  23. 31 Oct, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-10-31 16:17:59 by simonpj] · 317a1fd9
      simonpj authored
      Add hi-boot files for the new knot
      317a1fd9
    • simonpj's avatar
      [project @ 2001-10-31 15:22:53 by simonpj] · 61bfd5dd
      simonpj authored
      ------------------------------------------
      	Improved handling of scoped type variables
      	------------------------------------------
      
      The main effect of this commit is to allow scoped type variables
      in pattern bindings, thus
      
      	(x::a, y::b) = e
      
      This was illegal, but now it's ok.  a and b have the same scope
      as x and y.
      
      
      On the way I beefed up the info inside a type variable
      (TcType.TyVarDetails; c.f. IdInfo.GlobalIdDetails) which
      helps to improve error messages. Hence the wide ranging changes.
      Pity about the extra loop from Var to TcType, but can't be helped.
      61bfd5dd
  24. 25 Oct, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-10-25 14:30:43 by simonpj] · d5f94cc1
      simonpj authored
      -------------------------------------------------------
        Correct an error in the handling of implicit parameters
        -------------------------------------------------------
      
      	MERGE WITH STABLE BRANCH UNLESS HARD TO DO
      
      Mark Shields discovered a bug in the way that implicit parameters
      are dealt with by the type checker.  It's all a bit subtle, and
      is extensively documented in TcSimplify.lhs.
      
      This commit makes the code both simpler and more correct.  It subtly
      changes the way in which type signatures are treated, but not in a way
      anyone would notice: see notes with "Question 2: type signatures"
      in TcSimplify.lhs.
      d5f94cc1
    • sof's avatar
      [project @ 2001-10-25 02:13:10 by sof] · 9e933350
      sof authored
      - Pet peeve removal / code tidyup, replaced various sub-optimal
        uses of 'length' with something a bit better, i.e., replaced
        the following patterns
      
         *  length as `cmpOp` length bs
         *  length as `cmpOp` val   -- incl. uses where val == 1 and val == 0
         *  {take,drop,splitAt} (length as) bs
         *  length [ () | pat <- as ]
      
        with uses of misc Util functions.
      
        I'd be surprised if there's a noticeable reduction in running
        times as a result of these changes, but every little bit helps.
      
        [ The changes have been tested wrt testsuite/ - I'm seeing a couple
          of unexpected breakages coming from CorePrep, but I'm currently
          assuming that these are due to other recent changes. ]
      
      - compMan/CompManager.lhs: restored 4.08 compilability + some code
        cleanup.
      
      None of these changes are HEADworthy.
      9e933350
  25. 26 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-26 15:12:33 by simonpj] · e0d750be
      simonpj authored
      ------------------
      		Simon's big commit
      		------------------
      
      This commit, which I don't think I can sensibly do piecemeal, consists
      of the things I've been doing recently, mainly directed at making
      Manuel, George, and Marcin happier with RULES.
      
      
      Reogranise the simplifier
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      1. The simplifier's environment is now an explicit parameter.  This
      makes it a bit easier to figure out where it is going.
      
      2. Constructor arguments can now be arbitrary expressions, except
      when the application is the RHS of a let(rec).  This makes it much
      easier to match rules like
      
      	RULES
      	    "foo"  f (h x, g y) = f' x y
      
      In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
      constructor application where necessary.  In the occurrence analyser,
      there's a new piece of context info (OccEncl) to say whether a
      constructor app is in a place where it should be in ANF.  (Unless
      it knows this it'll give occurrence info which will inline the
      argument back into the constructor app.)
      
      3. I'm experimenting with doing the "float-past big lambda" transformation
      in the full laziness pass, rather than mixed in with the simplifier (was
      tryRhsTyLam).
      
      4.  Arrange that
      	case (coerce (S,T) (x,y)) of ...
      will simplify.  Previous it didn't.
      A local change to CoreUtils.exprIsConApp_maybe.
      
      5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
      error function in one branch.
      
      
      Phase numbers, RULES, and INLINE pragmas
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1.  Phase numbers decrease from N towards zero (instead of increasing).
      This makes it easier to add new earlier phases, which is what users want
      to do.
      
      2.  RULES get their own phase number, N, and are disabled in phases before N.
      
      e.g. 	{-# RULES "foo" [2] forall x y.  f (x,y) = f' x y #-}
      
      Note the [2], which says "only active in phase 2 and later".
      
      3.  INLINE and NOINLINE pragmas have a phase number to.  This is now treated
      in just the same way as the phase number on RULE; that is, the Id is not inlined
      in phases earlier than N.  In phase N and later the Id *may* be inlined, and
      here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
      as soon as it *may* be inlined it probably *will* be inlined.
      
      The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
      like the RULES case (i.e. in square brackets).  This should also make sure
      you examine all such phase numbers; many will need to change now the numbering
      is reversed.
      
      Inlining Ids is no longer affected at all by whether the Id appears on the
      LHS of a rule.  Now it's up to the programmer to put a suitable INLINE/NOINLINE
      pragma to stop it being inlined too early.
      
      
      Implementation notes:
      
      *  A new data type, BasicTypes.Activation says when a rule or inline pragma
      is active.   Functions isAlwaysActive, isNeverActive, isActive, do the
      obvious thing (all in BasicTypes).
      
      * Slight change in the SimplifierSwitch data type, which led to a lot of
      simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.
      
      * The InlinePragma in the IdInfo of an Id is now simply an Activation saying
      when the Id can be inlined.  (It used to be a rather bizarre pair of a
      Bool and a (Maybe Phase), so this is much much easier to understand.)
      
      * The simplifier has a "mode" environment switch, replacing the old
      black list.  Unfortunately the data type decl has to be in
      CmdLineOpts, because it's an argument to the CoreDoSimplify switch
      
          data SimplifierMode = SimplGently | SimplPhase Int
      
      Here "gently" means "no rules, no inlining".   All the crucial
      inlining decisions are now collected together in SimplMonad
      (preInlineUnconditionally, postInlineUnconditionally, activeInline,
      activeRule).
      
      
      Specialisation
      ~~~~~~~~~~~~~~
      1.  Only dictionary *functions* are made INLINE, not dictionaries that
      have no parameters.  (This inline-dictionary-function thing is Marcin's
      idea and I'm still not sure whether it's a good idea.  But it's definitely
      a Bad Idea when there are no arguments.)
      
      2.  Be prepared to specialise an INLINE function: an easy fix in
      Specialise.lhs
      
      But there is still a problem, which is that the INLINE wins
      at the call site, so we don't use the specialised version anyway.
      I'm still unsure whether it makes sense to SPECIALISE something
      you want to INLINE.
      
      
      
      
      
      Random smaller things
      ~~~~~~~~~~~~~~~~~~~~~~
      
      * builtinRules (there was only one, but may be more) in PrelRules are now
        incorporated.   They were being ignored before...
      
      * OrdList.foldOL -->  OrdList.foldrOL, OrdList.foldlOL
      
      * Some tidying up of the tidyOpenTyVar, tidyTyVar functions.  I've
        forgotten exactly what!
      e0d750be
  26. 07 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-07 12:34:03 by simonpj] · b8711eeb
      simonpj authored
      -------------------
      	Newtypes and ccalls
      	     [addendum]
      	-------------------
      
      	MERGE WITH STABLE BRANCH
      
      I accidentally omitted these two wibbles from my previous commit.
      I've added PrelNames.unitTyConKey, and used it in TcType and DsCCall.
      b8711eeb
  27. 06 Sep, 2001 1 commit
  28. 28 Aug, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-08-28 10:06:29 by simonpj] · b0604aad
      simonpj authored
      ----------------------------------------
      	Make isFFIArgumentTy understand newtypes
      	----------------------------------------
      
      This fixes the bug Manuel reported:
      
      	newtype T = T (Ptr T)
      	foreign import ccall foo :: T -> IO (Ptr T)
      
        test.hs:6:
            Unacceptable argument type in foreign declaration: T
      
      
      On the way, I moved isFFIArgumentTy and friends out of TysWiredIn,
      where they didn't really belong, into TcType.  That in turn force
      me to move isStrictType, and isPrimitiveType.
      b0604aad
  29. 14 Aug, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-08-14 06:35:56 by simonpj] · 2767767f
      simonpj authored
      1. Arrange that w/w records unfoldings
         And that the simplifier preserves them
      
      2. Greatly improve structure of checking user types in the typechecker
         Main changes:
      	TcMType.checkValidType checks for a valid type
      	TcMonoType.tcHsSigType uses checkValidType
      	Type and class decls use TcMonoType.tcHsType (which does not
      		check for validity) inside the knot in TcTyClsDecls,
      		and then runs TcTyDecls.checkValidTyCon
      		or TcClassDcl.checkValidClass to check for validity
      		once the knot is tied
      2767767f
  30. 23 Jul, 2001 1 commit
  31. 10 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-10 11:32:28 by simonpj] · c4786b4e
      simonpj authored
      Two bug-fixes to the new newtype story
      
      1. 	Be consistent about using TcType (not Type) in the
      	typechecker.  There was an odd function in TcMType that
      	used splitTyConApp instead of tcSplitTyConApp, which
      	resulted in bogus error messages
      
      2.	TcType.isTauTy should not look through SourceTy
      c4786b4e
  32. 25 Jun, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-06-25 14:36:04 by simonpj] · a5ded1f8
      simonpj authored
      Import wibbles
      a5ded1f8
    • simonpj's avatar
      [project @ 2001-06-25 08:09:57 by simonpj] · d069cec2
      simonpj authored
      ----------------
      	Squash newtypes
      	----------------
      
      This commit squashes newtypes and their coerces, from the typechecker
      onwards.  The original idea was that the coerces would not get in the
      way of optimising transformations, but despite much effort they continue
      to do so.   There's no very good reason to retain newtype information
      beyond the typechecker, so now we don't.
      
      Main points:
      
      * The post-typechecker suite of Type-manipulating functions is in
      types/Type.lhs, as before.   But now there's a new suite in types/TcType.lhs.
      The difference is that in the former, newtype are transparent, while in
      the latter they are opaque.  The typechecker should only import TcType,
      not Type.
      
      * The operations in TcType are all non-monadic, and most of them start with
      "tc" (e.g. tcSplitTyConApp).  All the monadic operations (used exclusively
      by the typechecker) are in a new module, typecheck/TcMType.lhs
      
      * I've grouped newtypes with predicate types, thus:
      	data Type = TyVarTy Tyvar | ....
      		  | SourceTy SourceType
      
      	data SourceType = NType TyCon [Type]
      			| ClassP Class [Type]
      			| IParam Type
      
      [SourceType was called PredType.]  This is a little wierd in some ways,
      because NTypes can't occur in qualified types.   However, the idea is that
      a SourceType is a type that is opaque to the type checker, but transparent
      to the rest of the compiler, and newtypes fit that as do implicit parameters
      and dictionaries.
      
      * Recursive newtypes still retain their coreces, exactly as before. If
      they were transparent we'd get a recursive type, and that would make
      various bits of the compiler diverge (e.g. things which do type comparison).
      
      * I've removed types/Unify.lhs (non-monadic type unifier and matcher),
      merging it into TcType.
      
      Ditto typecheck/TcUnify.lhs (monadic unifier), merging it into TcMType.
      d069cec2
  33. 21 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-21 09:19:14 by simonpj] · c7e7bc25
      simonpj authored
      -------------------------------
      	Improve pattern type-signatures
      	-------------------------------
      
      The main effect of this commit is to implement the idea (originally
      Marcin's suggestion) that type variables in pattern type signatures
      are simply names for types; they don't have to name a type that is
      itself a type variable.
      
      For example
      
      	f :: Int -> Int
      	f (x::a) = let  y::a
      			y = x
      		   in x+y
      
      is fine.  Here 'a' is a name for the type 'Int', and does not have
      to be universally quantified.
      
      
      I also took the opportunity to modularise the implementation of
      pattern type-checking, mainly in TcMatches.  As a result pattern type
      signatures should work in do-notation (which they didn't before).
      
      ToDo: update documentation
      c7e7bc25
  34. 30 Apr, 2001 1 commit