1. 26 Nov, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-11-26 10:33:40 by simonpj] · 5a1ac8dc
      simonpj authored
      Complete previous tcAddImportedIdInfo 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
      	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
      	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
      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
      All of this doesn't come entirely for free.  Here's the typechecker
      line count (INCLUDING comments)
      	Before	16,551
      	After	17,116
  2. 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.
  3. 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
      	    "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
      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,
      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
      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!
  4. 13 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-13 13:29:56 by simonpj] · d4e38936
      simonpj authored
      	Tidy up the "syntax rebinding" story
      I found a bug in the code that dealt with re-binding implicit
      numerical syntax:
      	literals 	(fromInteger/fromRational)
      	negation	(negate)
      	n+k patterns	(minus)
      This is triggered by the -fno-implicit-prelude flag, and it
      used to be handled via the PrelNames.SyntaxMap.
      But I found a nicer way to do it that involves much less code,
      and doesn't have the bug.  The explanation is with
  5. 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.
  6. 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
  7. 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
  8. 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
      	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
  9. 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.
  10. 28 Feb, 2001 1 commit
  11. 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.
  12. 23 Feb, 2001 2 commits
  13. 22 Feb, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-02-22 13:17:57 by simonpj] · be2c67eb
      simonpj authored
      Remove fromInt from class Num, though it is retained
      as an overloaded operation (with unchanged type) in PrelNum.
      There are quite a few consequential changes in the Prelude.
      I hope I got them all correct!
      Also fix a bug that meant Integer (and its instances)
      wasn't getting slurped in by the renamer, even though it
      was needed for defaulting.
  14. 20 Feb, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-02-20 09:40:43 by simonpj] · 5e624292
      simonpj authored
      Decoupling the Prelude [HsExpr, HsLit, HsPat, ParseUtil, Parser.y, PrelNames,
      ~~~~~~~~~~~~~~~~~~~~~~  Rename, RnEnv, RnExpr, RnHsSyn, Inst, TcEnv, TcMonad,
      			TcPat, TcExpr]
      The -fno-implicit-prelude flag is meant to arrange that when you write
      you get
      	fromInt 3
      where 'fromInt' is whatever fromInt is in scope at the top level of
      the module being compiled.  Similarly for
      	* numeric patterns
      	* n+k patterns
      	* negation
      This used to work, but broke when we made the static/dynamic flag distinction.
      It's now tidied up a lot.  Here's the plan:
        - PrelNames contains sugarList :: SugarList, which maps built-in names
          to the RdrName that should replace them.  
        - The renamer makes a finite map :: SugarMap, which maps the built-in names
          to the Name of the re-mapped thing
        - The typechecker consults this map via tcLookupSyntaxId when it is doing
          numeric things
      At present I've only decoupled numeric syntax, since that is the main demand,
      but the scheme is much more robustly extensible than the previous method.
      As a result some HsSyn constructors don't need to carry names in them
      (notably HsOverLit, NegApp, NPlusKPatIn)
  15. 25 Jan, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-01-25 17:54:24 by simonpj] · 4e342297
      simonpj authored
      	   Mainly FunDeps (23 Jan 01)
      This commit re-engineers the handling of functional dependencies.
      A functional dependency is no longer an Inst; instead, the necessary
      dependencies are snaffled out of their Class when necessary.
      As part of this exercise I found that I had to re-work how to do generalisation
      in a binding group.  There is rather exhaustive documentation on the new Plan
      at the top of TcSimplify.
      	WARNING: I have compiled all the libraries with this new compiler
      		 and all looks well, but I have not run many programs.
      		 Things may break.  Let me know if so.
      The main changes are these:
      1.  typecheck/TcBinds and TcSimplify have a lot of changes due to the
          new generalisation and context reduction story.  There are extensive
          comments at the start of TcSimplify
      2.  typecheck/TcImprove is removed altogether.  Instead, improvement is
          interleaved with context reduction (until a fixpoint is reached).
          All this is done in TcSimplify.
      3.  types/FunDeps has new exports
      	* 'improve' does improvement, returning a list of equations
      	* 'grow' and 'oclose' close a list of type variables wrt a set of
      	  PredTypes, but in slightly different ways.  Comments in file.
      4.  I improved the way in which we check that main::IO t.  It's tidier now.
      In addition
      *   typecheck/TcMatches:
      	a) Tidy up, introducing a common function tcCheckExistentialPat
      	b) Improve the typechecking of parallel list comprehensions,
      	   which wasn't quite right before.  (see comments with tcStmts)
      	WARNING: (b) is untested!  Jeff, you might want to check.
      *   Numerous other incidental changes in the typechecker
      *   Manuel found that rules don't fire well when you have partial applications
          from overloading.  For example, we may get
      	f a (d::Ord a) = let m_g = g a d
      			 \y :: a -> ...(m_g (h y))...
          The 'method' m_g doesn't get inlined because (g a d) might be a redex.
          Yet a rule that looks like
      		g a d (h y) = ...
          won't fire because that doesn't show up.  One way out would be to make
          the rule matcher a bit less paranoid about duplicating work, but instead
          I've added a flag
          which controls whether we generate things like m_g in the first place.
          It's not clear that they are a win in the first place.
          The flag is actually consulted in Inst.tcInstId
  16. 08 Dec, 2000 1 commit
  17. 24 Nov, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-11-24 17:02:01 by simonpj] · 83eef621
      simonpj authored
      1. Make the new version machinery work.
         I think it does now!
      2. Consequence of (1): Move the generation of
         default method names to one place (namely
         in RdrHsSyn.mkClassOpSigDM
      3. Major clean up on HsDecls.TyClDecl
         These big constructors should have been records
         ages ago, and they are now.  At last.
  18. 20 Nov, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-11-20 14:48:52 by simonpj] · c271b647
      simonpj authored
      When renaming, typechecking an expression from the user
      interface, we may suck in declarations from interface
      files (e.g. the Prelude).  This commit takes account of that.
      To do so, I did some significant restructuring in TcModule,
      with consequential changes and tidy ups elsewhere in the type
      checker.  I think there should be fewer lines in total than before.
  19. 15 Nov, 2000 1 commit
  20. 14 Nov, 2000 1 commit
  21. 07 Nov, 2000 1 commit
  22. 31 Oct, 2000 3 commits
  23. 30 Oct, 2000 2 commits
  24. 26 Oct, 2000 1 commit
  25. 25 Oct, 2000 1 commit
  26. 24 Oct, 2000 1 commit
  27. 23 Oct, 2000 2 commits
  28. 18 Oct, 2000 1 commit
  29. 17 Oct, 2000 5 commits
  30. 16 Oct, 2000 1 commit