1. 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
  2. 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
  3. 08 Nov, 2001 1 commit
    • sof's avatar
      [project @ 2001-11-08 19:20:55 by sof] · 56883a7f
      sof authored
      rnHsForeignDecl: 'foreign import's (incl 'f.e.d's) _define_ local toplevel
      names, so better use RnEnv.lookupTopBndrRn and not RnEnv.lookupOccRn to
      resolve the name.
      
      As was, declaring ForeignImports with the same name as an imported entity
      wasn't permitted.
      56883a7f
  4. 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
  5. 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
  6. 23 Aug, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-08-23 15:05:52 by simonpj] · f62fd70d
      simonpj authored
      More instance-gate fiddling.  This must be one of the most
      tiremsome bits of the entire compiler, and I appear to be
      incapable of modifying it without getting it wrong at least
      once.
      
      Still, this commit does tidy things up a bit.
      
      * The type renamers (rnHsType, etc) have moved from RnSource
        into a new module RnTypes.
      
      * This breaks a couple of loops, and lets us nuke RnSource.hi-boot.
        Hurrah!
      
      Simon
      f62fd70d
    • simonpj's avatar
      [project @ 2001-08-23 09:54:45 by simonpj] · 98bf5734
      simonpj authored
      --------------------------------------------------
      	Be a bit more liberal when slurping instance decls
      	--------------------------------------------------
      
      Functional dependencies have (as usual) made things more complicated
      
      Suppose an interface file contains
      	interface A where
      	  class C a b | a->b where op :: a->b
      	  instance C Foo Baz where ...
      
      Now we are compiling
      	module B where
      	  import A
      	  t = op (v::Foo)
      
      Should we slurp the instance decl, even though Baz is nowhere mentioned
      in module B?  YES!  Because of the fundep, the (C Foo ?) part is enough to
      select this instance decl, and the Baz part follows.
      
      Rather than take fundeps into account "properly", we just slurp
      if C is visible and *any one* of the Names in the types
      This is a slightly brutal approximation, but most instance decls
      are regular H98 ones and it's perfect for them.
      
      Changes:
      
        HscTypes:
      	generalise the types of GatedDecl a bit
      
        RnHiFiles.loadInstDecl, RnHiFiles.loadRule, RnIfaces.selectGated:
      	the meat of the solution
      
        RdrName, OccName etc:
      	some consequential wibbles
      98bf5734
  7. 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
  8. 23 Jul, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-07-23 10:54:46 by simonpj] · f6cd95ff
      simonpj authored
      ---------------------------------
      	Switch to the new demand analyser
      	---------------------------------
      
      This commit makes the new demand analyser the main beast,
      with the old strictness analyser as a backup.  When
      DEBUG is on, the old strictness analyser is run too, and the
      results compared.
      
      WARNING: this isn't thorougly tested yet, so expect glitches.
      Delay updating for a few days if the HEAD is mission critical
      for you.
      
      But do try it out.  I'm away for 2.5 weeks from Thursday, so
      it would be good to shake out any glaring bugs before then.
      f6cd95ff
  9. 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
  10. 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
  11. 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
  12. 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
  13. 03 May, 2001 1 commit
  14. 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
  15. 05 Apr, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-04-05 11:54:37 by simonpj] · 197a5ee7
      simonpj authored
      Make type synonyms work right in H98
      197a5ee7
    • simonpj's avatar
      [project @ 2001-04-05 11:31:26 by simonpj] · 11197236
      simonpj authored
      --------------------------------
      	Better grouping for ty/cls decls
      	--------------------------------
      
      When finding mutually-recursive groups of type and class decls,
      we shouldn't include classes mentioned in a deriving clause as
      edges. E.g.
      
      	class Eq a where ...
      
      	data Bool = True | False deriving( Eq )
      
      Eq and Bool are not mutually recursive.
      
      The edges are computed by RnHsSyn.tyClDeclFVs, so we remove the
      derivings from there.
      
      There a consequential fix in RnSource.rnSourceDecl
      11197236
  16. 13 Mar, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-03-13 14:58:25 by simonpj] · 788faebb
      simonpj authored
      ----------------
      	Nuke ClassContext
      	----------------
      
      This commit tidies up a long-standing inconsistency in GHC.
      The context of a class or instance decl used to be restricted
      to predicates of the form
      	C t1 .. tn
      with
      	type ClassContext = [(Class,[Type])]
      
      but everywhere else in the compiler we used
      
      	type ThetaType = [PredType]
      where PredType can be any sort of constraint (= predicate).
      
      The inconsistency actually led to a crash, when compiling
      	class (?x::Int) => C a where {}
      
      I've tidied all this up by nuking ClassContext altogether, and using
      PredType throughout.  Lots of modified files, but all in
      more-or-less trivial ways.
      
      I've also added a check that the context of a class or instance
      decl doesn't include a non-inheritable predicate like (?x::Int).
      
      Other things
      
       * rename constructor 'Class' from type TypeRep.Pred to 'ClassP'
         (makes it easier to grep for)
      
       * rename constructor HsPClass  => HsClassP
      		      HsPIParam => HsIParam
      788faebb
    • simonmar's avatar
      [project @ 2001-03-13 12:50:29 by simonmar] · 10cbc75d
      simonmar authored
      Some rearrangements that Simon & I have been working on recently:
      
          - CoreSat is now CorePrep, and is a general "prepare-for-code-
            generation" pass.  It does cloning, saturation of constructors &
            primops, A-normal form, and a couple of other minor fiddlings.
      
          - CoreTidy no longer does cloning, and minor fiddlings.  It doesn't
            need the unique supply any more, so that's removed.
      
          - CoreToStg now collects CafInfo and the list of CafRefs for each
            binding.  The SRT pass is much simpler now.
      
          - IdInfo now has a CgInfo field for "code generator info".  It currently
            contains arity (the actual code gen arity which affects the calling
            convention as opposed to the ArityInfo which is a measure of how
            many arguments the Id can be applied to before it does any work), and
            CafInfo.
      
            Previously we overloaded the ArityInfo field to contain both
            codegen arity and simplifier arity.  Things are cleaner now.
      
          - CgInfo is collected by CoreToStg, and passed back into CoreTidy in
            a loop.  The compiler will complain rather than going into a black
            hole if the CgInfo is pulled on too early.
      
          - Worker info in an interface file now comes with arity info attached.
            Previously the main arity info was overloaded for this purpose, but
            it lead to a few hacks in the compiler, this tidies things up somewhat.
      
      Bottom line: we removed several fragilities, and tidied up a number of
      things.  Code size should be smaller, but we'll see...
      10cbc75d
  17. 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
  18. 20 Dec, 2000 1 commit
  19. 19 Dec, 2000 3 commits
  20. 07 Dec, 2000 1 commit
  21. 30 Nov, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-11-30 15:46:01 by simonpj] · 28561da9
      simonpj authored
      Make the tests for -fglasgow-exts apply only to source code.
        If you merely import a module that uses (say) multi-parameter
        type classes internally, you shouldn't need -fglasgow-exts.
      
        There were surprisingly few places to change.
      28561da9
  22. 27 Nov, 2000 1 commit
  23. 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
  24. 10 Nov, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-11-10 15:12:50 by simonpj] · f23ba2b2
      simonpj authored
      1.	Outputable.PprStyle now carries a bit more information
      	In particular, the printing style tells whether to print
      	a name in unqualified form.  This used to be embedded in
      	a Name, but since Names now outlive a single compilation unit,
      	that's no longer appropriate.
      
      	So now the print-unqualified predicate is passed in the printing
      	style, not embedded in the Name.
      
         2.	I tidied up HscMain a little.  Many of the showPass messages
      	have migraged into the repective pass drivers
      f23ba2b2
  25. 07 Nov, 2000 1 commit
  26. 01 Nov, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-11-01 17:15:28 by simonpj] · 2ffefc1b
      simonpj authored
      More renamer commits
      
      Versioning now works properly I think.
      
      The main irritation is that interface files now have fuly-qualified names for
      *everything*, even things defined in that module.  This is a deficiency in
      the pretty printing for interface files.  Probable solution: add something
      to the SDoc styles.  But not today.
      2ffefc1b
  27. 31 Oct, 2000 2 commits
  28. 30 Oct, 2000 1 commit
  29. 25 Oct, 2000 2 commits
  30. 24 Oct, 2000 3 commits
  31. 19 Oct, 2000 1 commit