1. 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
  2. 28 Jun, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-06-28 14:06:52 by simonpj] · 33ce2a14
      simonpj authored
      -----------------------------------
      	Fix the CAF info field of error Ids
      	-----------------------------------
      
      A bizarre bug.   In MkId, we build the Id for various error-y
      Ids (like pAT_ERROR_ID) that we grab out of thin air in various
      places (like the desugarer).  They were marked as not referring
      to any CAFs, but this was a lie!  In fact, they refer to 'untangle'
      (see GHC.Err) and thence to a CAF.
      
      Result: GC crash under very obscure circumstances.  (Rob's optimistic
      evaluator tickled it.)
      
      Solution: give them more conservative IdInfo.
      
      Two other better solutions to think about:
      
      * Don't grab them out of thin air; instead get them from
        an interface file.
      
      * Treat them as always-live (requires mod to garbage collector)
        so they don't need to be mentioned in SRTs at all
      33ce2a14
  3. 14 Jun, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-06-14 14:03:25 by simonpj] · 990dd09b
      simonpj authored
      ---------------------------------------
      	Utterly expunge the tyGenInfo field of
      			an IdInfo
      	---------------------------------------
      
      tyGenInfo was a relic of a previous version of Keith's usage
      analyser.  It's just dead code, so I've nuked it.
      990dd09b
  4. 22 Apr, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-04-22 16:06:35 by simonpj] · dbfe93e6
      simonpj authored
      CPR control
      
      1.  Remove -fno-cpr, add -fcpr-off which is a simple static flag
          for switching the new CPR analysis off altogether.
          (The "-fno" machinery is rather complicated.)
      
      2.  Rejig SimplCore a little so that the "old strictness analyser"
          runs both the old strictness analyser and the old CPR analyser,
          which makes it more like the new strictness/CPR analyser.
      
          (How much longer we keep the old strictness/CPR analyser in the
          compiler at all I don't know.  It's just for comparision purposes
          when we write the paper.)
      dbfe93e6
  5. 04 Apr, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-04-04 13:15:18 by simonpj] · c44e1c41
      simonpj authored
      ---------------------------------------
      	A glorious improvement to CPR analysis
      	---------------------------------------
      
      Working on the CPR paper, I finally figured out how to
      do a decent job of taking account of strictness analyis when doing
      CPR analysis.
      
      There are two places we do that:
      
      1.  Usually, on a letrec for a *thunk* we discard any CPR info from
      the RHS.  We can't worker/wrapper a thunk.  BUT, if the let is
      	non-recursive
      	non-top-level
      	used strictly
      we don't need to discard the CPR info, because the thunk-splitting
      transform (WorkWrap.splitThunk) works.  This idea isn't new in this
      commit.
      
      
      2. Arguments to strict functions.  Consider
      
        fac n m = if n==0 then m
      		    else fac (n-1) (m*n)
      
      Does it have the CPR property?  Apparently not, because it returns the
      accumulating parameter, m.  But the strictness analyser will
      discover that fac is strict in m, so it will be passed unboxed to
      the worker for fac.  More concretely, here is the worker/wrapper
      split that will result from strictness analysis alone:
      
        fac n m = case n of MkInt n' ->
      	    case m of MkInt m' ->
      	    facw n' m'
      
        facw n' m' = if n' ==# 0#
      	       then I# m'
      	       else facw (n' -# 1#) (m' *# n')
      
      Now facw clearly does have the CPR property!  We can take advantage
      of this by giving a demanded lambda the CPR property.
      
      
      To make this work nicely, I've made NewDemandInfo into Maybe Demand
      rather than simply Demand, so that we can tell when we are on the
      first iteration.  Lots of comments about this in Note [CPR-AND-STRICTNESS].
      
      I don't know how much all this buys us, but it is simple and elegant.
      c44e1c41
  6. 15 Mar, 2002 1 commit
  7. 14 Mar, 2002 1 commit
  8. 11 Dec, 2001 3 commits
  9. 10 Dec, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-12-10 14:07:30 by simonmar] · 973539a8
      simonmar authored
      Make the inclusion of the old strictness analyser, CPR analyser, and
      the relevant IdInfo components, conditional on DEBUG.  This makes
      IdInfo smaller by three fields in a non-DEBUG compiler, and reduces
      the risk that the unused fields could harbour space leaks.
      
      Eventually these passes will go away altogether.
      973539a8
  10. 19 Nov, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-11-19 14:23:52 by simonpj] · d8af6b8c
      simonpj authored
      --------------------------------------
      	Yet another cut at the DmdAnal domains
      	--------------------------------------
      
      This version of the domain for demand analysis was developed
      in discussion with Peter Sestoft, so I think it might at last
      be more or less right!
      
      Our idea is mentally to separate
      	strictness analysis
      from
      	absence and boxity analysis
      
      Then we combine them back into a single domain.  The latter
      is all you see in the compiler (the Demand type, as before)
      but we understand it better now.
      d8af6b8c
  11. 25 Oct, 2001 1 commit
    • 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
  12. 23 Oct, 2001 1 commit
    • sof's avatar
      [project @ 2001-10-23 22:25:46 by sof] · 1181f398
      sof authored
      Deleted HsVersions.h #defines that were now past their use-by-dates; in
      particular, make the assumption that a post-Haskell 1.4 compiler is now
      used to compile ghc/compiler/
      
      Hanging on to those FastString #defines is probably not worth it any longer,
      either, but I punted on making that (much bigger) change.
      1181f398
  13. 18 Oct, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-10-18 16:29:12 by simonpj] · 685e04e4
      simonpj authored
      ----------------------------------------------
      	The CoreTidy/CorePrep/CoreToStg saga continues
      	[actually, this commit mostly completes the job]
      	----------------------------------------------
      
      			DO NOT MERGE!
      
      * CorePrep injects implicit bindings, not the type checker,
        nor CgConTbls.   (This way, all the code generators see
        them, so no need to fiddle with the byte code generator.)
      
        As a result, all bindings in the module are for LocalIds,
        at least until CoreTidy.   This is a Big Win.
      
        Hence remove nasty isImplicitId test in update_bndr in
        SimplCore and DmdAnal
      
      * hasNoBinding is no longer true of a dataConId (worker).
        There's an implicit curried binding for it.
      
      * Remove yukky test in exprIsTrivial that did not regard
        a hasNoBinding Id as trivial; similarly in SimplUtils.tryEtaReduce
      
      * In CoreTidy, get the names to avoid from the type env.
        That way it includes implicit bindings too.
      
      * CoreTidy set the Arity of a top-level Id permanently;
        it's up to the rest of the compiler to respect it.
        Notably, CorePrep uses etaExpand to make the manifest arity
        match the claimed arity.
      
      * As a result, nuke CgArity, so that CgInfo now contains only
        CafInfo.  The CafInfo is knot-tied as before.
      
      
      Other things
      
      * In Simplify.simplLazyBind, be a bit keener to float bindings
        out if it's a top-level binding.
      685e04e4
  14. 15 Oct, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-10-15 15:06:01 by simonpj] · 713b32a5
      simonpj authored
      --------------------------
      	Tidy up arity propagation
      	--------------------------
      
      Due to excessive complexity, correct arity information was getting
      lost on the way to interface files.  As a result, a function that had
      CPR info __S SLm (say), was getting arity 0, and this confused the (old)
      CPR analyser ("lub of function and HasCPR").
      
      I hope this fixes the above error (which showed up somewhere in
      compiling Edison), but I'm going to commit it right now anyway.
      Meanwhile I'll recompile Edison too.
      
      
      Details
      ~~~~~~~
      Digging out the rather obscure cause made me tidy up the CgInfo stuff.
      The story is now
      
      * The CgInfo field of an Id gets attached to the Id *only* in
        the TypeEnv of the ModuleDetails, during CoreTidy.
      
        This ModuleDetails stuff is used
      	a) to generate the interface file
      	b) to import into other modules in GHCi
      
      * No CgInfo field is in the CoreBindings which are passed
        downsteam to CorePrep and thence CodeGen.  Quite right too...
        it's the downstream stuff that *generates* the CgInfo.
      
      * But the Arity field *is* now passed on through CoreTidy
        (like strictness info) since it is usefully used by CorePrep.
      
      * On the way I simplified the ArityInfo field of an IdInfo
        to simply
      		Arity
        instead of
      		Maybe Arity
      713b32a5
  15. 03 Oct, 2001 1 commit
  16. 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
  17. 20 Sep, 2001 1 commit
  18. 11 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-11 08:18:16 by simonpj] · 3ea73c48
      simonpj authored
      -----------------------
      	More demand-info fixes
      	-----------------------
      
      	MERGE WITH STABLE BRANCH
      
      There are a handful of functions in IdInfo that zap the
      demand-info stored in an Id.  Alas, they were zapping the
      *old* demand-info not the new one.  (The old one is still
      there for comparison purposes.)  So we were getting some
      spurious warnings and (more seriously) potentially some
      incorrect strictness.  Easily fixed though.
      3ea73c48
  19. 07 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-07 12:42:46 by simonpj] · d3f61314
      simonpj authored
      ------------------------
      	Fix the demand analyser
      	------------------------
      
      A spiffy new domain for demands, and definitions for lub/both
      which are actually monotonic.   Quite a bit of related jiggling
      around.
      
      One of the original motivations was to do with functions like:
      
      	sum n []     = n
      	sum n (x:xs) = sum (n+x) xs
      
      Even though n is returned boxed from the first case, we don't want
      to get strictness
      	S(L)V -> T
      because that means we pass the box for n, and that is TERRIBLE.
      So the new version errs on the side of unboxing, more like the forwards
      analyser, and only passes the box if it is *definitely* needed, rather
      than if it *may* be needed.
      d3f61314
  20. 24 Aug, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-08-24 13:22:25 by simonpj] · 2daf21bb
      simonpj authored
      Make when comparing old and new strictness information,
      we were being a bit too generous with the old case.
      When a function has (say) arity 2, we can't use strictness
      info like SSS, because that only applies if the fn is
      applied to 3 args.  So it's an unfair comparison.
      
      This commit makes the old->new conversion function more
      truthful in this regard, which should eliminate the
      erroneously-claimed "worse" strictness results.
      2daf21bb
    • rrt's avatar
      [project @ 2001-08-24 09:41:27 by rrt] · 10f01216
      rrt authored
      Remove unused import of DmdType
      10f01216
  21. 24 Jul, 2001 1 commit
  22. 23 Jul, 2001 2 commits
    • qrczak's avatar
      [project @ 2001-07-23 11:44:15 by qrczak] · 8fe4dbdd
      qrczak authored
      import qualified Demand
      8fe4dbdd
    • simonpj's avatar
      [project @ 2001-07-23 10:54:46 by simonpj] · f6cd95ff
      simonpj authored
      ---------------------------------
      	Switch to the new demand analyser
      	---------------------------------
      
      This commit makes the new demand analyser the main beast,
      with the old strictness analyser as a backup.  When
      DEBUG is on, the old strictness analyser is run too, and the
      results compared.
      
      WARNING: this isn't thorougly tested yet, so expect glitches.
      Delay updating for a few days if the HEAD is mission critical
      for you.
      
      But do try it out.  I'm away for 2.5 weeks from Thursday, so
      it would be good to shake out any glaring bugs before then.
      f6cd95ff
  23. 20 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-20 15:22:21 by simonpj] · 0fa26afe
      simonpj authored
      -----------------------
      	Get rid of ArityAtLeast
      	-----------------------
      
      Now that we have CgInfo, with the exact code-generator arity
      for the value, we don't need the distinction between ArityAtLeast
      and ArityExactly in the ArityInfo field of an IdInfo.
      
      This commit makes
      
      	type ArityInfo = Maybe Arity
      
      and propagates this change consistently through the compiler.
      0fa26afe
  24. 19 Jul, 2001 1 commit
  25. 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
  26. 25 Jun, 2001 1 commit
    • 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
  27. 22 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-22 13:43:14 by simonpj] · f16228e4
      simonpj authored
      -------------------------------------------
      	Towards generalising 'foreign' declarations
      	-------------------------------------------
      
      This is a first step towards generalising 'foreign' declarations to
      handle langauges other than C.  Quite a lot of files are touched,
      but nothing has really changed.  Everything should work exactly as
      before.
      
      	But please be on your guard for ccall-related bugs.
      
      Main things
      
      Basic data types: ForeignCall.lhs
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      * Remove absCSyn/CallConv.lhs
      
      * Add prelude/ForeignCall.lhs.  This defines the ForeignCall
        type and its variants
      
      * Define ForeignCall.Safety to say whether a call is unsafe
        or not (was just a boolean).  Lots of consequential chuffing.
      
      * Remove all CCall stuff from PrimOp, and put it in ForeignCall
      
      
      Take CCallOp out of the PrimOp type (where it was always a glitch)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      * Add IdInfo.FCallId variant to the type IdInfo.GlobalIdDetails,
      	along with predicates Id.isFCallId, Id.isFCallId_maybe
      
      * Add StgSyn.StgOp, to sum PrimOp with FCallOp, because it
        *is* useful to sum them together in Stg and AbsC land.  If
        nothing else, it minimises changes.
      
      
      Also generally rename "CCall" stuff to "FCall" where it's generic
      to all foreign calls.
      f16228e4
  28. 14 May, 2001 1 commit
  29. 03 May, 2001 1 commit
  30. 13 Mar, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-03-13 12:50:29 by simonmar] · 10cbc75d
      simonmar authored
      Some rearrangements that Simon & I have been working on recently:
      
          - CoreSat is now CorePrep, and is a general "prepare-for-code-
            generation" pass.  It does cloning, saturation of constructors &
            primops, A-normal form, and a couple of other minor fiddlings.
      
          - CoreTidy no longer does cloning, and minor fiddlings.  It doesn't
            need the unique supply any more, so that's removed.
      
          - CoreToStg now collects CafInfo and the list of CafRefs for each
            binding.  The SRT pass is much simpler now.
      
          - IdInfo now has a CgInfo field for "code generator info".  It currently
            contains arity (the actual code gen arity which affects the calling
            convention as opposed to the ArityInfo which is a measure of how
            many arguments the Id can be applied to before it does any work), and
            CafInfo.
      
            Previously we overloaded the ArityInfo field to contain both
            codegen arity and simplifier arity.  Things are cleaner now.
      
          - CgInfo is collected by CoreToStg, and passed back into CoreTidy in
            a loop.  The compiler will complain rather than going into a black
            hole if the CgInfo is pulled on too early.
      
          - Worker info in an interface file now comes with arity info attached.
            Previously the main arity info was overloaded for this purpose, but
            it lead to a few hacks in the compiler, this tidies things up somewhat.
      
      Bottom line: we removed several fragilities, and tidied up a number of
      things.  Code size should be smaller, but we'll see...
      10cbc75d
  31. 08 Mar, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-03-08 12:07:38 by simonpj] · 51a571c0
      simonpj authored
      --------------------
      	A major hygiene pass
      	--------------------
      
      1. The main change here is to
      
      	Move what was the "IdFlavour" out of IdInfo,
      	and into the varDetails field of a Var
      
         It was a mess before, because the flavour was a permanent attribute
         of an Id, whereas the rest of the IdInfo was ephemeral.  It's
         all much tidier now.
      
         Main places to look:
      
      	   Var.lhs	Defn of VarDetails
      	   IdInfo.lhs	Defn of GlobalIdDetails
      
         The main remaining infelicity is that SpecPragmaIds are right down
         in Var.lhs, which seems unduly built-in for such an ephemeral thing.
         But that is no worse than before.
      
      
      2. Tidy up the HscMain story a little.  Move mkModDetails from MkIface
         into CoreTidy (where it belongs more nicely)
      
         This was partly forced by (1) above, because I didn't want to make
         DictFun Ids into a separate kind of Id (which is how it was before).
         Not having them separate means we have to keep a list of them right
         through, rather than pull them out of the bindings at the end.
      
      3. Add NameEnv as a separate module (to join NameSet).
      
      4. Remove unnecessary {-# SOURCE #-} imports from FieldLabel.
      51a571c0
  32. 01 Mar, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-03-01 17:10:06 by simonpj] · 09518039
      simonpj authored
      Improve IdInfo substitution
      
      To get rules to work nicely, we need to make rules for recursive functions
      active in the RHS of the very recursive function itself.  This can be
      done nicely: the change is to move the calls to simplIdInfo in Simplify
      to an earlier place.
      
      The second thing is that when doing simple expression substitution
      in a rule (which we do during simplification for rules attached to an Id)
      we were zapping the occurrence info carefully pinned on the rule binders
      when the rule was put into the Id's rules.  This in turn meant that
      the simplifer ran more iterations than necessary when rules were fired.
      (Andrew Tolmach discovered this.)
      
      So I tidied up the interface to Subst a little.  The relevant functions
      that have changed are
      	simplBndr, simplBndrs, simplLetId, simplIdInfo,
      	substAndCloneId, substAndCloneIds, substAndCloneRecIds,
      
      There are consequential changes in other modules, but it compiles
      at least the whole standard libraries happily, and the codegen tests,
      so I'm reasonably confident in it.  But watch out for new strange
      happenings.
      09518039
  33. 26 Feb, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-02-26 15:06:57 by simonmar] · 1c62b517
      simonmar authored
      Implement do-style bindings on the GHCi command line.
      
      The syntax for a command-line is exactly that of a do statement, with
      the following meanings:
      
        - `pat <- expr'
          performs expr, and binds each of the variables in pat.
      
        - `let pat = expr; ...'
          binds each of the variables in pat, doesn't do any evaluation
      
        - `expr'
          behaves as `it <- expr' if expr is IO-typed, or `let it = expr'
          followed by `print it' otherwise.
      1c62b517
  34. 25 Jan, 2001 1 commit
  35. 20 Dec, 2000 1 commit
  36. 08 Dec, 2000 1 commit