1. 23 Jan, 2003 1 commit
  2. 11 Nov, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-11-11 10:53:28 by simonpj] · 0adb7175
      simonpj authored
      ------------------
        	   Fix a newtype-deriving bug
      		------------------
      
      The new newtype-deriving mechanism was erroneously using the
      *representation type* of the newtype.  The rep type looks through all
      ihtermediate newtypes, so that is wrong.  See Note [newtype
      representation] in TcDeriv.lhs
      
      deriving/should_run/drvrun013 now tests for this.
      0adb7175
  3. 25 Oct, 2002 1 commit
  4. 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
  5. 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
  6. 21 Jun, 2002 1 commit
  7. 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
  8. 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
  9. 05 Apr, 2002 1 commit
  10. 01 Apr, 2002 1 commit
    • simonpj's avatar
      [project @ 2002-04-01 08:23:30 by simonpj] · 9003a18c
      simonpj authored
      ------------------------------------
      	Change the treatment of the stupid
      	   context on data constructors
      	-----------------------------------
      
      Data types can have a context:
      
      	data (Eq a, Ord b) => T a b = T1 a b | T2 a
      
      and that makes the constructors have a context too
      (notice that T2's context is "thinned"):
      
      	T1 :: (Eq a, Ord b) => a -> b -> T a b
      	T2 :: (Eq a) => a -> T a b
      
      Furthermore, this context pops up when pattern matching
      (though GHC hasn't implemented this, but it is in H98, and
      I've fixed GHC so that it now does):
      
      	f (T2 x) = x
      gets inferred type
      	f :: Eq a => T a b -> a
      
      I say the context is "stupid" because the dictionaries passed
      are immediately discarded -- they do nothing and have no benefit.
      It's a flaw in the language.
      
      Up to now I have put this stupid context into the type of
      the "wrapper" constructors functions, T1 and T2, but that turned
      out to be jolly inconvenient for generics, and record update, and
      other functions that build values of type T (because they don't
      have suitable dictionaries available).
      
      So now I've taken the stupid context out.  I simply deal with
      it separately in the type checker on occurrences of a constructor,
      either in an expression or in a pattern.
      
      To this end
      
      * Lots of changes in DataCon, MkId
      
      * New function Inst.tcInstDataCon to instantiate a data constructor
      
      
      
      I also took the opportunity to
      
      * Rename
      	dataConId --> dataConWorkId
        for consistency.
      
      * Tidied up MkId.rebuildConArgs quite a bit, and renamed it
      	mkReboxingAlt
      
      * Add function DataCon.dataConExistentialTyVars, with the obvious meaning
      9003a18c
  11. 13 Feb, 2002 1 commit
  12. 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
  13. 01 Feb, 2002 1 commit
  14. 28 Dec, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-12-28 17:25:31 by simonpj] · ae969b47
      simonpj authored
      ---------------------
      	Dealing with deriving
      	---------------------
      
      I spent a ridiculously long time peering at a bug report whereby
      a 'deriving' clause sent GHC 5.02.1 into a loop.  It was all to
      do with allowing instances like
      
      	instance Foo a b => Baz (T a)
      
      (Notice the 'b' on the left which does not appear on the right.)
      
      I realised that it's hard for the deriving machinery to find a
      fixpoint when these sort of instance decls are around.  So I
      now constrain *derived* instance decls not to have this form;
      all the tyvars on the left must appear on the right.
      
      On the way I commoned up the previously-separate tcSimplify
      machinery for 'deriving' and 'default' decls with that for
      everything else.   As a result, quite a few files are touched.
      
      I hope I havn't broken anything.
      ae969b47
  15. 21 Dec, 2001 2 commits
  16. 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
  17. 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
  18. 03 Dec, 2001 1 commit
  19. 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
  20. 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
  21. 13 Mar, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-03-13 16:57:34 by simonpj] · 8f7d8614
      simonpj authored
      Add error location for deriving failure errors
      8f7d8614
    • 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
  22. 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
  23. 23 Feb, 2001 1 commit
  24. 03 Jan, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-01-03 11:18:51 by simonmar] · 20d387c4
      simonmar authored
      s/boxed/lifted/
      
      The typechecker's notion of "boxed" versus "unboxed" kind should
      really have been "unlifted" versus "lifted" instead.  It is illegal to
      unify an unlifted (but boxed) type with a polymorphic type variable,
      since an unlifted/boxed type is always assumed to be a pointer to the
      object itself, never a thunk or indirection.
      
      This commit removes isUnboxedType, and renames a bunch of things that
      were previously boxed/unboxed to unlifted/lifted.
      20d387c4
  25. 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
  26. 15 Nov, 2000 1 commit
    • simonpj's avatar
      [project @ 2000-11-15 14:37:08 by simonpj] · 8b653a82
      simonpj authored
      The main thing in this commit is to change StgAlts so that
      it carries a TyCon, and not a Type.  Furthermore, the TyCon
      is derived from the alternatives, so it should have its
      constructors etc, even if there's a module loop involved, so that
      some versions of the TyCon don't have the constructors visible.
      
      There's a comment in StgSyn.lhs, with the type decl for StgAlts
      
      
      Also: a start on hscExpr in HscMain.
      8b653a82
  27. 06 Nov, 2000 1 commit
  28. 31 Oct, 2000 2 commits
  29. 25 Oct, 2000 1 commit
  30. 24 Oct, 2000 3 commits
  31. 23 Oct, 2000 2 commits
  32. 18 Oct, 2000 1 commit
  33. 17 Oct, 2000 1 commit