1. 20 Feb, 2003 2 commits
    • simonpj's avatar
      [project @ 2003-02-20 18:33:50 by simonpj] · 56b5a8b8
      simonpj authored
      -------------------------------------
            Add Core Notes and the {-# CORE #-} pragma
      	-------------------------------------
      
      This is an idea of Hal Daume's. The key point is that Notes in Core
      are augmented thus:
      
        data Note
          = SCC CostCentre
          | ...
          | CoreNote String     -- NEW
      
      These notes can be injected via a Haskell-source pragma:
      
         f x = ({-# CORE "foo" #-} show) ({-# CORE "bar" #-} x)
      
      This wraps a (Note (CoreNote "foo")) around the 'show' variable,
      and a similar note around the argument to 'show'.
      
      These notes are basically ignored by GHC, but are emitted into
      External Core, where they may convey useful information.
      
      Exactly how code involving these notes is munged by the simplifier
      isn't very well defined.  We'll see how it pans out.  Meanwhile
      the impact on the rest of the compiler is minimal.
      56b5a8b8
    • simonpj's avatar
      [project @ 2003-02-20 13:17:02 by simonpj] · f6176af6
      simonpj authored
      Comments only
      f6176af6
  2. 18 Feb, 2003 1 commit
  3. 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
  4. 04 Feb, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-02-04 12:28:22 by simonpj] · 115f0fae
      simonpj authored
      ---------------------------------------------------
      	Important fix to the handling of class methods that
      	      mention their own class type variable
      	---------------------------------------------------
      
      [NB: I'm not 100% certain that this commit is independent of the
           Template-Haskell-related commit I'm doing at the same time.
           I've tried to separate them but may not have succeeded totally.]
      
      This bug gives utterly bogus (detected by Core Lint) programs.
      Isaac Jones discovered it.  Here's an example, now enshrined as tc165.
      
          class C a where
      	f :: (Eq a) => a
      
          instance C () where
      	f = f
      
      The instance decl was translated as
      
          dfC() = MkC (let f = \dEq -> f in f)
      
      which is utterly wrong.  Reason: the 'f' on the left was being treated
      as an available Inst, but it doesn't obey INVARIANT 2 for Insts, which
      is that they are applied to all their dictionaries.  (See the data type
      decl for Inst.)
      
      Solution: don't include such class methods in the available Insts.
      115f0fae
  5. 23 Jan, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-01-23 14:54:35 by simonpj] · 9aba9a7f
      simonpj authored
      Suppress "No explicit method or default decl given for m"
      	if the method name starts with an underscore
      
      	This in response to a suggestion by George Russel
      9aba9a7f
  6. 13 Jan, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-01-13 17:01:22 by simonpj] · 0877011a
      simonpj authored
      ------------------------------------
      	(a) Improve reporting of staging errors
      	(b) Tidy up the construction of dict funs
      			and default methods
      	------------------------------------
      0877011a
  7. 18 Nov, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-11-18 14:25:50 by simonpj] · 4e84be0c
      simonpj authored
      ----------------------------------------
      	Class ops that do not introduce for-alls
      	----------------------------------------
      
      	MERGE TO STABLE (if poss)
      
      The handling of class ops that do not add an extra for-all
      was utterly bogus.  For example:
      
      	class C a where
      	    fc :: (?p :: String) => a;
      
      	class D a where
      	    fd :: (Ord a) => [a] -> [a]
      
      De-bogus-ing means
      
      a) Being careful when taking apart the class op type in
      	MkIface.tcClassOpSig
      
      b) Ditto when making the method Id in an instance binding.
         Hence new function Inst.tcInstClassOp, and its calls
         in TcInstDcls, and TcClassDcls
      4e84be0c
  8. 18 Oct, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-10-18 13:41:50 by simonpj] · f53483a2
      simonpj authored
      --------------------------------
         Fix a serious error in the "newtype deriving" feature
      	--------------------------------
      
      The "newtype deriving" feature lets you derive arbitrary classes for
      a newtype, not just the built-in ones (Read, Show, Ix etc).  It's very
      cool, but Hal Duame discovered that it did utterly the Wrong Thing
      for superclasses.  E.g.
      
      	newtype Foo = MkFoo Int deriving( Show, Num, Eq )
      
      You'd get a Num instance for Foo that was *identical* to the
      Num instance for Int, *including* the Show superclass. So the
      superclass in the Num dictionary would show a Foo just like an
      Int, which is wrong... it should show as "Foo n".
      
      This commit fixes the problem, by building a new dictionary every time,
      but using the methods from the dictionary for the representation type.
      
      I also fixed a bug that prevented it working altogether when the
      representation type was not the application of a type constructor.
      For example, this now works
      
      	newtype Foo a = MkFoo a deriving( Num, Eq, Show )
      
      
      I also made it a bit more efficient in the case where the type is
      not parameterised.  Then the "dfun" doesn't need to be a function.
      f53483a2
  9. 27 Sep, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-09-27 08:20:43 by simonpj] · dbc254c3
      simonpj authored
      --------------------------------
              Implement recursive do-notation
      	--------------------------------
      
      This commit adds recursive do-notation, which Hugs has had for some time.
      
      	mdo { x <- foo y ;
      	      y <- baz x ;
      	      return (y,x) }
      
      turns into
      
      	do { (x,y) <- mfix (\~(x,y) -> do { x <- foo y;
      					    y <- baz x }) ;
      	     return (y,x) }
      
      This is all based on work by Levent Erkok and John Lanuchbury.
      
      The really tricky bit is in the renamer (RnExpr.rnMDoStmts) where
      we break things up into minimal segments.  The rest is easy, including
      the type checker.
      
      Levent laid the groundwork, and Simon finished it off. Needless to say,
      I couldn't resist tidying up other stuff, so there's no guaranteed I
      have not broken something.
      dbc254c3
  10. 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
  11. 09 Sep, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-09-09 12:55:52 by simonpj] · 5e392a56
      simonpj authored
      --------------------------------------
      	Attach inline pragmas to class methods
      	--------------------------------------
      
      This fix makes INLINE pragmas on method bindings (in class
      or instance decls) work properly.
      
      It seems to have been hanging around in my tree for some time.
      To be on the safe side, let's not merge this into 5.04.1, although
      it should be fine (an an improvement).
      5e392a56
  12. 02 Sep, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-09-02 16:37:13 by simonpj] · 210cba68
      simonpj authored
      Fix an obscure bug in the creation of default methods for class
      ops with higher-rank type.   See the comments with
      		TcClassDcl.mkDefMethRhs
      
      Test is should_compile/tc161
      
      		MERGE TO STABLE
      210cba68
  13. 29 Apr, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-04-29 14:03:38 by simonmar] · b085ee40
      simonmar authored
      FastString cleanup, stage 1.
      
      The FastString type is no longer a mixture of hashed strings and
      literal strings, it contains hashed strings only with O(1) comparison
      (except for UnicodeStr, but that will also go away in due course).  To
      create a literal instance of FastString, use FSLIT("..").
      
      By far the most common use of the old literal version of FastString
      was in the pattern
      
      	  ptext SLIT("...")
      
      this combination still works, although it doesn't go via FastString
      any more.  The next stage will be to remove the need to use this
      special combination at all, using a RULE.
      
      To convert a FastString into an SDoc, now use 'ftext' instead of
      'ptext'.
      
      I've also removed all the FAST_STRING related macros from HsVersions.h
      except for SLIT and FSLIT, just use the relevant functions from
      FastString instead.
      b085ee40
  14. 11 Apr, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-04-11 12:03:29 by simonpj] · a7b95beb
      simonpj authored
      -------------------
      	Mainly derived Read
      	-------------------
      
      This commit is a tangle of several things that somehow got wound up
      together, I'm afraid.
      
      
      The main course
      ~~~~~~~~~~~~~~~
      Replace the derived-Read machinery with Koen's cunning new parser
      combinator library.   The result should be
      	* much smaller code sizes from derived Read
      	* faster execution of derived Read
      
      WARNING: I have not thoroughly tested this stuff; I'd be glad if you did!
      	 All the hard work is done, but there may be a few nits.
      
      The Read class gets two new methods, not exposed
      in the H98 inteface of course:
        class Read a where
          readsPrec    :: Int -> ReadS a
          readList     :: ReadS [a]
          readPrec     :: ReadPrec a		-- NEW
          readListPrec :: ReadPrec [a]	-- NEW
      
      There are the following new libraries:
      
        Text.ParserCombinators.ReadP		Koens combinator parser
        Text.ParserCombinators.ReadPrec	Ditto, but with precedences
      
        Text.Read.Lex				An emasculated lexical analyser
      					that provides the functionality
      					of H98 'lex'
      
      TcGenDeriv is changed to generate code that uses the new libraries.
      The built-in instances of Read (List, Maybe, tuples, etc) use the new
      libraries.
      
      
      Other stuff
      ~~~~~~~~~~~
      1. Some fixes the the plumbing of external-core generation. Sigbjorn
      did most of the work earlier, but this commit completes the renaming and
      typechecking plumbing.
      
      2. Runtime error-generation functions, such as GHC.Err.recSelErr,
      GHC.Err.recUpdErr, etc, now take an Addr#, pointing to a UTF8-encoded
      C string, instead of a Haskell string.  This makes the *calls* to these
      functions easier to generate, and smaller too, which is a good thing.
      
      In particular, it means that MkId.mkRecordSelectorId doesn't need to
      be passed "unpackCStringId", which was GRUESOME; and that in turn means
      that tcTypeAndClassDecls doesn't need to be passed unf_env, which is
      a very worthwhile cleanup.   Win/win situation.
      
      3.  GHC now faithfully translates do-notation using ">>" for statements
      with no binding, just as the report says.  While I was there I tidied
      up HsDo to take a list of Ids instead of 3 (but now 4) separate Ids.
      Saves a bit of code here and there.  Also introduced Inst.newMethodFromName
      to package a common idiom.
      a7b95beb
  15. 01 Apr, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-04-01 08:23:30 by simonpj] · 9003a18c
      simonpj authored
      ------------------------------------
      	Change the treatment of the stupid
      	   context on data constructors
      	-----------------------------------
      
      Data types can have a context:
      
      	data (Eq a, Ord b) => T a b = T1 a b | T2 a
      
      and that makes the constructors have a context too
      (notice that T2's context is "thinned"):
      
      	T1 :: (Eq a, Ord b) => a -> b -> T a b
      	T2 :: (Eq a) => a -> T a b
      
      Furthermore, this context pops up when pattern matching
      (though GHC hasn't implemented this, but it is in H98, and
      I've fixed GHC so that it now does):
      
      	f (T2 x) = x
      gets inferred type
      	f :: Eq a => T a b -> a
      
      I say the context is "stupid" because the dictionaries passed
      are immediately discarded -- they do nothing and have no benefit.
      It's a flaw in the language.
      
      Up to now I have put this stupid context into the type of
      the "wrapper" constructors functions, T1 and T2, but that turned
      out to be jolly inconvenient for generics, and record update, and
      other functions that build values of type T (because they don't
      have suitable dictionaries available).
      
      So now I've taken the stupid context out.  I simply deal with
      it separately in the type checker on occurrences of a constructor,
      either in an expression or in a pattern.
      
      To this end
      
      * Lots of changes in DataCon, MkId
      
      * New function Inst.tcInstDataCon to instantiate a data constructor
      
      
      
      I also took the opportunity to
      
      * Rename
      	dataConId --> dataConWorkId
        for consistency.
      
      * Tidied up MkId.rebuildConArgs quite a bit, and renamed it
      	mkReboxingAlt
      
      * Add function DataCon.dataConExistentialTyVars, with the obvious meaning
      9003a18c
  16. 27 Mar, 2002 1 commit
  17. 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
  18. 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
  19. 05 Feb, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-02-05 15:42:04 by simonpj] · e6601808
      simonpj authored
      ```------
      		Main.main
      		---------
      
      A bunch of related fixes concerning 'main'
      
      * Arrange that 'main' doesn't need to be defined in module Main;
        it can be imported.
      
      * The typechecker now injects a binding
      	Main.$main = PrelTopHandler.runMain main
      
        So the runtime system now calls Main.$main, not PrelMain.main.
        With z-encoding, this look like
      		Main_zdmain_closure
      
      * The function
        	PrelTopHandler.runMain :: IO a -> IO ()
        wraps the programmer's 'main' in an exception-cacthing wrapper.
      
      * PrelMain.hs and Main.hi-boot are both removed from lib/std, along
        with multiple lines of special case handling in lib/std/Makefile.
        This is a worthwhile cleanup.
      
      * Since we now pick up whatever 'main' is in scope, the ranamer gets
        in on the act (RnRnv.checkMain).  There is a little more info to
        get from the renamer to the typechecker, so I've defined a new type
        Rename.RnResult (c.f. TcModule.TcResult)
      
      * With GHCi, it's now a warning, not an error, to omit the binding
        of main (RnEnv.checkMain)
      
      * It would be easy to add a flag "-main-is foo"; the place to use
        that information is in RnEnv.checkMain.
      ```
      
      ----
      
      On the way I made a new type,
      	type HscTypes.FixityEnv = NameEnv Fixity
      and used it in various places I'd tripped over
      e6601808
  20. 30 Jan, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-01-30 17:16:36 by simonpj] · dd214d28
      simonpj authored
      -----------------------------
      	Tidy up the top level of TcModule
      	-----------------------------
      
      This commit started life as sorting out the TcInstDcls thing that
      we got wrong a few weeks back, but it spiraled out of control.
      
      However, the result is a nice tidy up of TcModule.
      
      typecheckModule/tcModule compiles a module from source code
      typecheckIface/tcIface   compiles a module from its interface file
      typecheckStmt		 compiles a Stmt
      typecheckExpr		 compiles a Expr
      
      tcExtraDecls is used by typecheckStmt/typecheckExpr
      	to compile interface-file decls.
      	It is just a wrapper for:
      
      tcIfaceImports, which is used by tcExtraDecls and tcIface
      	to compile interface file-file decls.
      
      tcImports, is similar to tcIfaceImports, but is used only by tcModule
      
      tcIfaceImports is used when compiling an interface, and can
      	therefore be quite a bit simpler
      dd214d28
  21. 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
  22. 23 Nov, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-11-23 12:06:49 by simonmar] · dd823536
      simonmar authored
      Use (DefMeth Name) rather than (DefMeth Id) in ClassOpItem.  This not
      only eliminates a space leak, because Names generally hold on to much
      less stuff than Ids, but also turns out to be a minor cleanup.
      dd823536
  23. 31 Oct, 2001 1 commit
    • 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 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
  25. 17 Oct, 2001 1 commit
  26. 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
  27. 07 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-07 12:44:30 by simonpj] · 991a868b
      simonpj authored
      ----------------------------------------
      	Make dict funs and default methods
      	into LocalIds only at their binding site
      	----------------------------------------
              [part of 3 related commits]
      
      There's a long comment about this with MkId.mkDefaultMethodId,
      which I reproduce below.
      
      While I was at it, I renamed setIdNoDiscard to setIdLocalExported.
      Which is hardly an improvement, I'm afraid.  This renaming touches
      	Var.lhs, Id.lhs, SimplCore.lhs
      in a trivial way.
      
      	---------------------
      
      Dict funs and default methods are *not* ImplicitIds.  Their definition
      involves user-written code, so we can't figure out their strictness etc
      based on fixed info, as we can for constructors and record selectors (say).
      
      We build them as GlobalIds, but when in the module where they are
      bound, we turn the Id at the *binding site* into an exported LocalId.
      This ensures that they are taken to account by free-variable finding
      and dependency analysis (e.g. CoreFVs.exprFreeVars).   The simplifier
      will propagate the LocalId to all occurrence sites.
      
      Why shouldn't they be bound as GlobalIds?  Because, in particular, if
      they are globals, the specialiser floats dict uses above their defns,
      which prevents good simplifications happening.  Also the strictness
      analyser treats a occurrence of a GlobalId as imported and assumes it
      contains strictness in its IdInfo, which isn't true if the thing is
      bound in the same module as the occurrence.
      
      It's OK for dfuns to be LocalIds, because we form the instance-env to
      pass on to the next module (md_insts) in CoreTidy, afer tidying
      and globalising the top-level Ids.
      
      BUT make sure they are *exported* LocalIds (setIdLocalExported) so
      that they aren't discarded by the occurrence analyser.
      991a868b
  28. 24 Aug, 2001 1 commit
  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
    • 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
  31. 12 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-12 16:21:22 by simonpj] · ab46fd8e
      simonpj authored
      --------------------------------------------
      	Fix another bug in the squash-newtypes story.
      	--------------------------------------------
      
      [This one was spotted by Marcin, and is now enshrined in test tc130.]
      
      The desugarer straddles the boundary between the type checker and
      Core, so it sometimes needs to look through newtypes/implicit parameters
      and sometimes not.  This is really a bit painful, but I can't think of
      a better way to do it.
      
      The only simple way to fix things was to pass a bit more type
      information in the HsExpr type, from the type checker to the desugarer.
      That led to the non-local changes you can see.
      
      On the way I fixed one other thing.  In various HsSyn constructors
      there is a Type that is bogus (bottom) before the type checker, and
      filled in with a real type by the type checker.  In one place it was
      a (Maybe Type) which was Nothing before, and (Just ty) afterwards.
      I've defined a type synonym HsTypes.PostTcType for this, and a named
      bottom value HsTypes.placeHolderType to use when you want the bottom
      value.
      ab46fd8e
  32. 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
  33. 18 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-18 08:46:18 by simonpj] · b4775e5e
      simonpj authored
      -----------------------------
      	Get unbox-strict-fields right
      	-----------------------------
      
      The problem was that when a library was compiled *without* -funbox-strict-fields,
      and the main program was compiled *with* that flag, we were wrongly treating
      the fields of imported data types as unboxed.
      
      To fix this I added an extra constructor to StrictnessMark to express whether
      the "!" annotation came from an interface file (don't fiddle) or a source
      file (decide whether to unbox).
      
      On the way I tided things up:
      
      * StrictnessMark moves to Demand.lhs, and doesn't have the extra DataCon
        fields that kept it in DataCon before.
      
      * HsDecls.BangType has one constructor, not three, with a StrictnessMark field.
      
      * DataCon keeps track of its strictness signature (dcRepStrictness), but not
        its "user strict marks" (which were never used)
      
      * All the functions, like getUniquesDs, that used to take an Int saying how
        many uniques to allocate, now return an infinite list. This saves arguments
        and hassle.  But it involved touching quite a few files.
      
      * rebuildConArgs takes a list of Uniques to use as its unique supply.  This
        means I could combine DsUtils.rebuildConArgs with MkId.rebuildConArgs
        (hooray; the main point of the previous change)
      
      
      I also tidied up one or two error messages
      b4775e5e
  34. 13 Mar, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-03-13 14:58:25 by simonpj] · 788faebb
      simonpj authored
      ----------------
      	Nuke ClassContext
      	----------------
      
      This commit tidies up a long-standing inconsistency in GHC.
      The context of a class or instance decl used to be restricted
      to predicates of the form
      	C t1 .. tn
      with
      	type ClassContext = [(Class,[Type])]
      
      but everywhere else in the compiler we used
      
      	type ThetaType = [PredType]
      where PredType can be any sort of constraint (= predicate).
      
      The inconsistency actually led to a crash, when compiling
      	class (?x::Int) => C a where {}
      
      I've tidied all this up by nuking ClassContext altogether, and using
      PredType throughout.  Lots of modified files, but all in
      more-or-less trivial ways.
      
      I've also added a check that the context of a class or instance
      decl doesn't include a non-inheritable predicate like (?x::Int).
      
      Other things
      
       * rename constructor 'Class' from type TypeRep.Pred to 'ClassP'
         (makes it easier to grep for)
      
       * rename constructor HsPClass  => HsClassP
      		      HsPIParam => HsIParam
      788faebb
  35. 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
  36. 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
  37. 20 Feb, 2001 2 commits
  38. 29 Jan, 2001 1 commit