1. 11 Dec, 2001 1 commit
  2. 07 Dec, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-12-07 17:33:26 by simonpj] · 8cc5cc27
      simonpj authored
      ----------------------------
      	More jiggling in the renamer
      	----------------------------
      
      I was a little hasty before.  (Thanks Sigbjorn for finding
      this.)  This commit tidies up the handling of AvailEnvs.
      Principally:
      
        * filterImports now deals completely with hiding
          (before it handed off part of the job to mkGlobalRdrEnv)
      
        * The AvailEnv in an ExportAvails does not have class ops and
          data constructors in its domain.  This makes plusExportAvails
          more efficient, but the main thing is that it collects things
          up right.  (Previously, if we had
      	import M( C )
      	import M( op )
          then we got an AvailEnv which had C |-> AvailTC C [C]
          (no 'op').
      
        * In Rename, we do need a "filled-out" version of the overall
          AvailEnv, full_avail_env, which we construct on the spot in 'rename'.
      8cc5cc27
    • sof's avatar
      [project @ 2001-12-07 07:37:43 by sof] · 24279879
      sof authored
      Tidyup - previous instance-decl commit fell a bit short:
      
       * RnEnv.lookupInstDeclBndr unceremoniously fell over when passed
         an out-of-scope class name.
      
       * the AvailEnv carried around didn't common up type/class info
         (i.e.,  AvailTCs), but rather type/class and method/label names,
         causing the renamer to (semi)randomly report instance methods as
         being out-of-scope in the presence of multiple imports for a module.
      
       * didn't support 'hiding' of class / method names (for the purposes
         of checking instance decls).
      24279879
  3. 06 Dec, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-12-06 10:45:42 by simonpj] · 61fae1d3
      simonpj authored
      --------------------------
      	Fix the instance-decl wart
      	--------------------------
      
      This commit implements the (proposed) H98 rule for
      resolving the class-method name in an instance decl.
      
      	module M( C( op1, op2 ) ) where
      		-- NB: op3 not exported
      	  class C a where
      	    op1, op2, op3 :: a -> a
      
      
      	module N where
      	  import qualified M as P( C )
      	  import qualified M as Q hiding( op2 )
      
      	  instance P.C Int where
      	    op1 x = x
      	    -- op2, op3 both illegal here
      
      The point is that
        a) only methods that can be named are legal
           in the instance decl
      	(so op2, op3 are not legal)
        b) but it doesn't matter *how* they can be named
      	(in this case Q.op1 is in scope, though
      	the class is called P.C)
      
      The AvailEnv carries the information about what's in scope,
      so we now have to carry it around in the monad, so that
      instance decl bindings can see it.  Quite simple really.
      
      Same deal for export lists. E.g.
      
      	module N( P.C( op1 ) ) where
      	  import qualified M as P( C )
      	  import qualified M as Q hiding( op2 )
      
      Actually this is what GHC has always implemented!
      61fae1d3
  4. 29 Nov, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-11-29 13:47:09 by simonpj] · 32a89583
      simonpj authored
      ------------------------------
      	Add linear implicit parameters
      	------------------------------
      
      Linear implicit parameters are an idea developed by Koen Claessen,
      Mark Shields, and Simon PJ, last week.  They address the long-standing
      problem that monads seem over-kill for certain sorts of problem, notably:
      
      	* distributing a supply of unique names
      	* distributing a suppply of random numbers
      	* distributing an oracle (as in QuickCheck)
      
      
      Linear implicit parameters are just like ordinary implicit parameters,
      except that they are "linear" -- that is, they cannot be copied, and
      must be explicitly "split" instead.  Linear implicit parameters are
      written '%x' instead of '?x'.  (The '/' in the '%' suggests the
      split!)
      
      For example:
      
          data NameSupply = ...
      
          splitNS :: NameSupply -> (NameSupply, NameSupply)
          newName :: NameSupply -> Name
      
          instance PrelSplit.Splittable NameSupply where
      	split = splitNS
      
      
          f :: (%ns :: NameSupply) => Env -> Expr -> Expr
          f env (Lam x e) = Lam x' (f env e)
      		    where
      		      x'   = newName %ns
      		      env' = extend env x x'
          ...more equations for f...
      
      Notice that the implicit parameter %ns is consumed
      	once by the call to newName
      	once by the recursive call to f
      
      So the translation done by the type checker makes
      the parameter explicit:
      
          f :: NameSupply -> Env -> Expr -> Expr
          f ns env (Lam x e) = Lam x' (f ns1 env e)
      		       where
      	 		 (ns1,ns2) = splitNS ns
      			 x' = newName ns2
      			 env = extend env x x'
      
      Notice the call to 'split' introduced by the type checker.
      How did it know to use 'splitNS'?  Because what it really did
      was to introduce a call to the overloaded function 'split',
      ndefined by
      
      	class Splittable a where
      	  split :: a -> (a,a)
      
      The instance for Splittable NameSupply tells GHC how to implement
      split for name supplies.  But we can simply write
      
      	g x = (x, %ns, %ns)
      
      and GHC will infer
      
      	g :: (Splittable a, %ns :: a) => b -> (b,a,a)
      
      The Splittable class is built into GHC.  It's defined in PrelSplit,
      and exported by GlaExts.
      
      Other points:
      
      * '?x' and '%x' are entirely distinct implicit parameters: you
        can use them together and they won't intefere with each other.
      
      * You can bind linear implicit parameters in 'with' clauses.
      
      * You cannot have implicit parameters (whether linear or not)
        in the context of a class or instance declaration.
      
      
      Warnings
      ~~~~~~~~
      The monomorphism restriction is even more important than usual.
      Consider the example above:
      
          f :: (%ns :: NameSupply) => Env -> Expr -> Expr
          f env (Lam x e) = Lam x' (f env e)
      		    where
      		      x'   = newName %ns
      		      env' = extend env x x'
      
      If we replaced the two occurrences of x' by (newName %ns), which is
      usually a harmless thing to do, we get:
      
          f :: (%ns :: NameSupply) => Env -> Expr -> Expr
          f env (Lam x e) = Lam (newName %ns) (f env e)
      		    where
      		      env' = extend env x (newName %ns)
      
      But now the name supply is consumed in *three* places
      (the two calls to newName,and the recursive call to f), so
      the result is utterly different.  Urk!  We don't even have
      the beta rule.
      
      Well, this is an experimental change.  With implicit
      parameters we have already lost beta reduction anyway, and
      (as John Launchbury puts it) we can't sensibly reason about
      Haskell programs without knowing their typing.
      
      Of course, none of this is throughly tested, either.
      32a89583
  5. 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
  6. 19 Nov, 2001 1 commit
  7. 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
  8. 23 Oct, 2001 1 commit
  9. 22 Oct, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-10-22 16:08:10 by simonmar] · a5caedcb
      simonmar authored
      -fwarn-name-shadowing should check the global env as well as the local
      env for names that could be shadowed (the docs don't say anything
      about it applying to local names only).
      a5caedcb
  10. 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
  11. 20 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-20 08:47:13 by simonpj] · 2c250999
      simonpj authored
      ------------------------------
      	Fix a scoped-type-variable bug
      	------------------------------
      
      	MERGE WITH STABLE BRANCH
      
      The bug caused an incorrect failure when the same type
      variable was used more than once in a collection of patterns:
      
      	f (x :: t) (y :: t) = e
      
      On the way, I eliminated bindNakedTyVarsFVRn, which was only
      called once.
      2c250999
  12. 13 Sep, 2001 1 commit
  13. 10 Sep, 2001 1 commit
  14. 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
      	RnEnv.lookupSyntaxName
      d4e38936
  15. 12 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-12 14:51:28 by simonpj] · 6d1815b0
      simonpj authored
      Fix the module import story to match what the Revised
      Haskell Report says
      
      1. 	Don't import qualified names of things that aren't imported
      
      2.	Fix a bug that meant
      		import A hiding( D )
      	where D is a data constructor, didn't work.
      	[The fix is to use IEVar not IEThingAbs in the
      	want_hiding case of get_item in RnNames.filterImports
      6d1815b0
  16. 27 Jun, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-06-27 16:38:17 by simonmar] · 47108330
      simonmar authored
      When we're in --interactive or --make mode, we don't even *look* for
      interface files in the home package.
      
      This means that cd'ing into fptools/ghc/lib/std and starting up GHCi
      Just Works, which is a good thing.  It also subsumes the previous hack
      about checking whether we're renaming a command-line expression before
      allowing a home interface to be loaded.
      
      The downside is that if you try to use a qualified name for a home
      module that's not loaded, you'll get a slightly less informative error
      message: "interface file not found" rather than "module not loaded",
      but this could be improved.
      47108330
  17. 11 Jun, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-06-11 12:24:51 by simonpj] · 2c6d73e2
      simonpj authored
      --------------------------------------
      	Tidy up and improve "pattern contexts"
      	--------------------------------------
      
      In various places (renamer, typechecker, desugarer) we need to know
      what the context of a pattern match is (case expression, function defn,
      let binding, etc).  This commit tidies up the story quite a bit.  I
      think it represents a net decrease in code, and certainly it improves the
      error messages from:
      
      	f x x = 3
      
      Prevsiously we got a message like "Conflicting bindings for x in a pattern match",
      but not it says "..in a defn of function f".
      
      WARNING: the tidy up had a more global effect than I originally expected,
      so it's possible that some other error messages look a bit peculiar.  They
      should be easy to fix, but tell us!
      2c6d73e2
  18. 28 May, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-05-28 13:57:19 by simonmar] · 2e63bea6
      simonmar authored
      When we auto-load a module because the user typed a qualified name at
      the prompt, we better not auto-load a home interface (because we won't
      have the code to go with it).
      
      So, introduce a new constructor in the WhereFrom datatype, namely
      ImportByCmdLine for these auto-imports, and make findAndReadIface fail
      if it tries to load a home interface by this route.
      
      ToDo: GHCi should *never* demand-load a home interface under any
      circumstances, but we don't have an ASSERT for this yet.
      2e63bea6
  19. 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
  20. 16 May, 2001 1 commit
  21. 30 Apr, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-04-30 10:51:18 by simonpj] · e7b69c55
      simonpj authored
      -----------------------------
      	Better filtering for warnings
      	-----------------------------
      
      * Add Opt_WarnMisc, to enable warnings not otherwise covered by Opt_Warn*
        in the renamer
      
      * Add RnMonad.ifOptRn :: DynFlag -> RnM d a -> RnM d ()
        and use it many places instead of the clumsy direct code
      e7b69c55
  22. 23 Mar, 2001 1 commit
  23. 22 Mar, 2001 1 commit
  24. 14 Mar, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-03-14 23:19:42 by simonpj] · d7296ca1
      simonpj authored
      -------------------------------
      	Fix the dreaded export list bug
      	-------------------------------
      
      With unfailing regularity I manage to get the following wrong:
      
      	module A(f) where 
      	  f = ...
      
      	module B(f) where
      	  import A(f)
      
      We must ensure that if A.f changes its type (etc) then B.hi
      gets changed, so that people who import B will get recompiled.
      
      There's a large comment with RnIfaces.mkImportInfo, and some
      reorganisation in Rename, with a few mainly cosmetic consequences
      in RnEnv.
      
      [Simon: I think this will fix the 'OccurAnal not recompiled' problem.]
      d7296ca1
  25. 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
  26. 01 Mar, 2001 1 commit
  27. 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
  28. 22 Feb, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-02-22 13:17:57 by simonpj] · be2c67eb
      simonpj authored
      fromInt
      
      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.
      be2c67eb
  29. 21 Feb, 2001 1 commit
  30. 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
      	3
      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)
      5e624292
  31. 06 Feb, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-02-06 17:31:00 by simonmar] · 787f3286
      simonmar authored
      Qualified names on the command line may now refer to any exported
      entity from any module, not just entities from the "original" defining
      module.
      
      eg. "IO.hFlush IO.stdout" now works.
      
      There's still a problem in that home interfaces may be demand-loaded
      if they're aren't already in memory, which is wrong (you can refer to
      a module which isn't loaded, causing things to fall over at link
      time).
      787f3286
  32. 18 Jan, 2001 2 commits
    • simonmar's avatar
      [project @ 2001-01-18 12:54:16 by simonmar] · 0ef29fb8
      simonmar authored
      Make the GHCi command line behave as if an "import qualified M" was in
      force for all M.
      
      The renamer now has a new "mode": CmdLineMode, which changes the
      lookup machinery to turn a qualified lookup into an original name
      lookup if the qualified name isn't otherwise in scope.
      0ef29fb8
    • simonmar's avatar
      [project @ 2001-01-18 11:16:08 by simonmar] · 95d8fef4
      simonmar authored
      When constructing a GlobalRdrEnv from an interface file for use from
      the GHCi command line, don't export the qualified names: a module
      which happens to export f from module M shouldn't bring into scope the
      qualified identifier M.f when we use it from the command line.
      95d8fef4
  33. 19 Dec, 2000 1 commit
  34. 08 Dec, 2000 1 commit
  35. 07 Dec, 2000 1 commit
  36. 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.
      83eef621
  37. 21 Nov, 2000 1 commit
  38. 20 Nov, 2000 1 commit