1. 20 Feb, 2003 1 commit
  2. 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
  3. 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
  4. 21 Nov, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-11-21 11:31:34 by simonpj] · a06f5e7b
      simonpj authored
      --------------------------------
      	Compile instance declarations better
      	--------------------------------
      
      This commit makes the type checker build better dictionaries
      from instance declarations.  "Better" in the sense that if a
      binding in the instance declaration mentions one of the other
      methods of the same class, we use that method directly rather
      than going via a (recursive) use of the dictionary.
      
      This makes it easier to unravel recursive knots, and that
      makes more inlining happen.  There's a long comment in
      TcInstDcls.tcMethods
      
      Makes the Monad instance for ST much more inlinable, and that
      makes spectral/fibheaps go faster, among other things.
      a06f5e7b
  5. 19 Nov, 2002 1 commit
  6. 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
  7. 05 Nov, 2002 1 commit
  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. 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
  10. 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
  11. 18 Jun, 2002 1 commit
  12. 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
  13. 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
  14. 02 Apr, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-04-02 13:21:36 by simonpj] · 13878c13
      simonpj authored
      -----------------------------------------------------
      	Fix two nasty, subtle loops in context simplification
      	-----------------------------------------------------
      
      The context simplifier in TcSimplify was building a recursive
      dictionary, which meant the program looped when run.  The reason
      was pretty devious; in fact there are two independent causes.
      
      Cause 1
      ~~~~~~~
      Consider
       	class Eq b => Foo a b
      	instance Eq a => Foo [a] a
      If we are reducing
      	d:Foo [t] t
      we'll first deduce that it holds (via the instance decl), thus:
      	d:Foo [t] t = $fFooList deq
      	deq:Eq t = ...some rhs depending on t...
      Now we add d's superclasses.  We must not then overwrite the Eq t
      constraint with a superclass selection!!
      
      The only decent way to solve this is to track what dependencies
      a binding has; that is what the is_loop parameter to TcSimplify.addSCs
      now does.
      
      
      Cause 2
      ~~~~~~~
      This shows up when simplifying the superclass context of an
      instance declaration.  Consider
      
        class S a
      
        class S a => C a where { opc :: a -> a }
        class S b => D b where { opd :: b -> b }
      
        instance C Int where
           opc = opd
      
        instance D Int where
           opd = opc
      
      From (instance C Int) we get the constraint set {ds1:S Int, dd:D Int}
      Simplifying, we may well get:
      	$dfCInt = :C ds1 (opd dd)
      	dd  = $dfDInt
      	ds1 = $p1 dd
      Notice that we spot that we can extract ds1 from dd.
      
      Alas!  Alack! We can do the same for (instance D Int):
      
      	$dfDInt = :D ds2 (opc dc)
      	dc  = $dfCInt
      	ds2 = $p1 dc
      
      And now we've defined the superclass in terms of itself.
      
      
      Solution: treat the superclass context separately, and simplify it
      all the way down to nothing on its own.  Don't toss any 'free' parts
      out to be simplified together with other bits of context.
      
      This is done in TcInstDcls.tcSuperClasses, which is well commented.
      
      All this from a bug report from Peter White!
      13878c13
  15. 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
  16. 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
  17. 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
  18. 31 Jan, 2002 1 commit
  19. 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
  20. 22 Jan, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-01-22 13:35:36 by simonmar] · 483817dd
      simonmar authored
      Attempt to fix the problems with missing instances once more.
      
      The current problem is that in the case where a ModDetails is being
      constructed from its interface (in compilation manager modes) we
      weren't getting any instances because the instances are gotten from
      the [InstInfo] returned from tcInstDecls1, which only contains
      *source* instance declarations.  Fix: return a list of DFuns defined
      in the current module from tcInstDecls1, to be plugged into the
      ModDetails later.
      
      Also: revert the previous change to the isLocalThing predicate,
      because now we really want to know which dfuns come from the current
      module.  The comment about the iface_dfuns containing only package and
      local instances is incorrect in batch-compile mode, because we also
      demand-load stuff from home package interfaces, so I deleted this
      comment and fixed up some of the other commentary.
      483817dd
  21. 18 Jan, 2002 1 commit
  22. 08 Jan, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-01-08 17:31:30 by simonmar] · bee714f2
      simonmar authored
      Fix a problem which lead to home-package instances ending up in the
      package instance table in GHCi, which results in strange duplicate
      instance errors when reloading modules.  See the comments for details.
      bee714f2
  23. 20 Dec, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-12-20 17:10:00 by simonpj] · f3695b15
      simonpj authored
      Wibbles
      f3695b15
    • simonpj's avatar
      [project @ 2001-12-20 11:19:05 by simonpj] · 91c750cb
      simonpj authored
      ---------------------------------------------
      	More type system extensions (for John Hughes)
      	---------------------------------------------
      
      1.  Added a brand-new extension that lets you derive ARBITRARY CLASSES
      for newtypes.  Thus
      
      	newtype Age = Age Int deriving( Eq, Ord, Shape, Ix )
      
      The idea is that the dictionary for the user-defined class Shape Age
      is *identical* to that for Shape Int, so there is really no deriving
      work to do.   This saves you writing the very tiresome instance decl:
      
      	instance Shape Age where
      	   shape_op1 (Age x) = shape_op1 x
      	   shape_op2 (Age x1) (Age x2) = shape_op2 x1 x2
      	   ...etc...
      
      It's more efficient, too, becuase the Shape Age dictionary really
      will be identical to the Shape Int dictionary.
      
      There's an exception for Read and Show, because the derived instance
      *isn't* the same.
      
      There is a complication where higher order stuff is involved.  Here is
      the example John gave:
      
         class StateMonad s m | m -> s where ...
      
         newtype Parser tok m a = Parser (State [tok] (Failure m) a)
      			  deriving( Monad, StateMonad )
      
      Then we want the derived instance decls to be
      
         instance Monad (State [tok] (Failure m)) => Monad (Parser tok m)
         instance StateMonad [tok] (State [tok] (Failure m))
      	 => StateMonad [tok] (Parser tok m)
      
      John is writing up manual entry for all of this, but this commit
      implements it.   I think.
      
      
      2.  Added -fallow-incoherent-instances, and documented it.  The idea
      is that sometimes GHC is over-protective about not committing to a
      particular instance, and the programmer may want to say "commit anyway".
      Here's the example:
      
          class Sat a where
            dict :: a
      
          data EqD a = EqD {eq :: a->a->Bool}
      
          instance Sat (EqD a) => Eq a where
            (==) = eq dict
      
          instance Sat (EqD Integer) where
            dict = EqD{eq=(==)}
      
          instance Eq a => Sat (EqD a) where
            dict = EqD{eq=(==)}
      
          class Collection c cxt | c -> cxt where
            empty :: Sat (cxt a) => c a
            single :: Sat (cxt a) => a -> c a
            union :: Sat (cxt a) => c a -> c a -> c a
            member :: Sat (cxt a) => a -> c a -> Bool
      
          instance Collection [] EqD where
            empty = []
            single x = [x]
            union = (++)
            member = elem
      
      It's an updated attempt to model "Restricted Data Types", if you
      remember my Haskell workshop paper. In the end, though, GHC rejects
      the program (even with fallow-overlapping-instances and
      fallow-undecideable-instances), because there's more than one way to
      construct the Eq instance needed by elem.
      
      Yet all the ways are equivalent! So GHC is being a bit over-protective
      of me, really: I know what I'm doing and I would LIKE it to pick an
      arbitrary one. Maybe a flag fallow-incoherent-instances would be a
      useful thing to add?
      91c750cb
  24. 26 Nov, 2001 3 commits
    • simonpj's avatar
      [project @ 2001-11-26 10:33:40 by simonpj] · 5a1ac8dc
      simonpj authored
      Complete previous tcAddImportedIdInfo commit
      5a1ac8dc
    • simonpj's avatar
      [project @ 2001-11-26 10:26:59 by simonpj] · 1fdd97b6
      simonpj authored
      --------------------------------------
      	Finally get rid of tcAddImportedIdInfo
      	--------------------------------------
      
      TcEnv.tcAddImportedIdInfo is a notorious source of space leaks.
      Simon M got rid of the need for it on default methods.
      This commit gets rid of the need for it for dictionary function Ids,
      and finally nukes the beast altogether. Hurrah!
      
      The change really involves putting tcInterfaceSigs *before*
      tcInstDecls1, so that any imported DFunIds are in the typechecker's
      environment before we get to tcInstDecls.
      1fdd97b6
    • 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 21 Aug, 2001 1 commit
  31. 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
  32. 27 Jun, 2001 1 commit
  33. 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
  34. 24 May, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-05-24 13:59:09 by simonpj] · cbdeae8f
      simonpj authored
      ------------------------------------------------------
      	More stuff towards generalising 'foreign' declarations
      	------------------------------------------------------
      
      This is the second step towards generalising 'foreign' declarations to
      handle langauges other than C.  Now I can handle
      
        foreign import dotnet type T
        foreign import dotnet "void Foo.Baz.f( T )" f :: T -> IO ()
      
      
      
      			** WARNING **
      	I believe that all the foreign stuff for C should
      	work exactly as before, but I have not tested it
      	thoroughly.  Sven, Manuel, Marcin: please give it a
      	whirl and compare old with new output.
      
      
      Lots of fiddling around with data types.  The main changes are
      
      * HsDecls.lhs
      	The ForeignDecl type and its friends
      	Note also the ForeignType constructor to TyClDecl
      
      * ForeignCall.lhs
      	Here's where the stuff that survives right through
      	compilation lives
      
      * TcForeign.lhs DsForeign.lhs
      	Substantial changes driven by the new data types
      
      * Parser.y ParseIface.y RnSource
      	Just what you'd expect
      cbdeae8f
  35. 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
  36. 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
  37. 04 May, 2001 1 commit