1. 13 Nov, 2007 1 commit
  2. 05 Nov, 2007 1 commit
  3. 16 Oct, 2007 1 commit
  4. 03 Oct, 2007 1 commit
  5. 29 Sep, 2007 2 commits
  6. 02 Oct, 2007 1 commit
  7. 29 Sep, 2007 1 commit
  8. 19 Sep, 2007 1 commit
  9. 15 Sep, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Overhaul of the rewrite rules · 6d2b0ae3
      chak@cse.unsw.edu.au. authored
      - Cleaned up and simplified rules
      - Added many missing cases
      - The rules OccursCheck and swap have been eliminated and integrate with
        the other rules; ie, Subst and Unify perform the occurs check themselves
        and they can deal with left-to-right and right-to-left oriented rewrites.
        This makes the code simpler and more efficient.
      - Also added comments.
      6d2b0ae3
  10. 11 Sep, 2007 1 commit
  11. 10 Sep, 2007 2 commits
    • Simon Marlow's avatar
      FIX #903: mkWWcpr: not a product · 3b1438a9
      Simon Marlow authored
      This fixes the long-standing bug that prevents some code with
      mutally-recursive modules from being compiled with --make and -O,
      including GHC itself.  See the comments for details.
      
      There are some additional cleanups that were forced/enabled by this
      patch: I removed importedSrcLoc/importedSrcSpan: it wasn't adding any
      useful information, since a Name already contains its defining Module.
      In fact when re-typechecking an interface file we were wrongly
      replacing the interesting SrcSpans in the Names with boring
      importedSrcSpans, which meant that location information could degrade
      after reloading modules.  Also, recreating all these Names was a waste
      of space/time.
      3b1438a9
    • chak@cse.unsw.edu.au.'s avatar
  12. 07 Sep, 2007 2 commits
  13. 05 Sep, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Refactor, improve, and document the deriving mechanism · 25f84fa7
      simonpj@microsoft.com authored
      This patch does a fairly major clean-up of the code that implements 'deriving.
      
      * The big changes are in TcDeriv, which is dramatically cleaned up.
        In particular, there is a clear split into
      	a) inference of instance contexts for deriving clauses
      	b) generation of the derived code, given a context 
        Step (a) is skipped for standalone instance decls, which 
        have an explicitly provided context.
      
      * The handling of "taggery", which is cooperative between TcDeriv and
        TcGenDeriv, is cleaned up a lot
      
      * I have added documentation for standalone deriving (which was 
        previously wrong).
      
      * The Haskell report is vague on exactly when a deriving clause should
        succeed.  Prodded by Conal I have loosened the rules slightly, thereyb
        making drv015 work again, and documented the rules in the user manual.
      
      I believe this patch validates ok (once I've update the test suite)
      and can go into the 6.8 branch.
      25f84fa7
  14. 04 Sep, 2007 1 commit
  15. 03 Sep, 2007 1 commit
  16. 01 Sep, 2007 1 commit
  17. 28 Aug, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Type checking for type synonym families · 5822cb8d
      chak@cse.unsw.edu.au. authored
      This patch introduces type checking for type families of which associated
      type synonyms are a special case. E.g.
      
              type family Sum n m
      
              type instance Sum Zero n = n
              type instance Sum (Succ n) m = Succ (Sum n m)
      
      where
      
              data Zero       -- empty type
              data Succ n     -- empty type
      
      In addition we support equational constraints of the form:
      
              ty1 ~ ty2
      
      (where ty1 and ty2 are arbitrary tau types) in any context where
      type class constraints are already allowed, e.g.
      
              data Equals a b where
                      Equals :: a ~ b => Equals a b
      
      The above two syntactical extensions are disabled by default. Enable
      with the -XTypeFamilies flag.
      
      For further documentation about the patch, see:
      
              * the master plan
                http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions
      
              * the user-level documentation
                http://haskell.org/haskellwiki/GHC/Indexed_types
      
      The patch is mostly backwards compatible, except for:
      
              * Some error messages have been changed slightly.
      
              * Type checking of GADTs now requires a bit more type declarations:
                not only should the type of a GADT case scrutinee be given, but also
                that of any identifiers used in the branches and the return type.
      
      Please report any unexpected behavior and incomprehensible error message 
      for existing code.
      
      Contributors (code and/or ideas):
              Tom Schrijvers
              Manuel Chakravarty
              Simon Peyton-Jones
              Martin Sulzmann 
      with special thanks to Roman Leshchinskiy
      5822cb8d
  18. 09 Aug, 2007 1 commit
  19. 03 Aug, 2007 1 commit
  20. 04 Aug, 2007 1 commit
  21. 06 Jul, 2007 1 commit
  22. 02 Jul, 2007 1 commit
  23. 29 Jun, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Many comments about oclose, plus a fix for Trac #1456 · 0f5731ee
      simonpj@microsoft.com authored
      There was a rather subtle bug in the way 'oclose' works when
      generalising top-level function definitions.  See
      	Note [Important subtlety in oclose]
      in FunDeps for an explanatoin.
      
      I also tidied up duplication in comments while I was here.
      0f5731ee
    • chak@cse.unsw.edu.au.'s avatar
      Overlap check for type families · 5a3ada9c
      chak@cse.unsw.edu.au. authored
      - If two "type instance"s overlap, they right-hand sides must be syntactically
        equal under the overlap substitution.  (Ie, we admit limited overlap, but
        require the system to still be confluent.)
      5a3ada9c
  24. 28 Jun, 2007 1 commit
  25. 25 Jun, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Print infix type constructors in an infix way · b15724ad
      simonpj@microsoft.com authored
      Fixes Trac #1425.  The printer for types doesn't know about fixities.
      (It could be educated to know, but it doesn't at the moment.)  So it
      treats all infix tycons as of precedence less than application and function
      arrrow.
      
      I took a slight shortcut and reused function-arrow prededence, so I think
      you may get
      	T -> T :% T
      meaning
      	T -> (T :% T)
      
      If that becomes a problem we can fix it.
      b15724ad
  26. 23 May, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Improve the interaction of 'seq' and associated data types · 9670d664
      simonpj@microsoft.com authored
      Roman produced programs involving associated types that did not optimise well.
      His programs were something like this:
      
        data family T a
        data instance T Int = MkT Bool Char
      
        bar :: T Int -> Int
        bar t = t `seq` loop 0
      	where
      	  loop = ...
      
      You'd think that the `seq` should unbox 't' outside the loop, since
      a (T Int) is just a MkT pair.  
      
      The most robust way to make this happen is for the simplifier to understand
      a bit about type-family instances.   See 
      	Note [Improving seq]
      in Simplify.lhs.  We use FamInstEnv.topNormaliseType to do the interesting
      work.
      
      To make this happen I did a bit of refactoring to the simplifier
      monad.
      
      I'd previously done a very similar transformation in LiberateCase, but it
      was happening too late.  So this patch takes it out of LiberateCase as
      well as adding it to Simplify.
      
      
      9670d664
    • simonpj@microsoft.com's avatar
      White-space only · 87b3c589
      simonpj@microsoft.com authored
      87b3c589
  27. 11 May, 2007 1 commit
  28. 19 May, 2007 1 commit
  29. 14 May, 2007 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Revised signature of tcLookupFamInst and lookupFamInstEnv · 4899cc82
      chak@cse.unsw.edu.au. authored
      - This changes the signature of FamInstEnv.lookupFamInstEnv and
        FamInstEnv.lookupFamInstEnvUnify in a manner similar to SPJ's
        previous patch for InstEnv.llokupInstEnv
      - tcLookupFamInst now permits the lookup of instances that are more
        general than the type instance requested.
      4899cc82
  30. 11 May, 2007 2 commits
  31. 09 May, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up the interface to lookupInstEnv · 2c8701fb
      simonpj@microsoft.com authored
      This patch changes the interface to lookupInstEnv, so that it
      returns a pair (Instance, [Either TyVar Type])
      rather than    (Inst,     TvSubst)
      
      There is no functionality change, but the interface is tidier,
      and closer to lookupFamInstEnv (when Manuel has changed that too).
      The [Either TyVar Type] gives the type(s) at which the dfun should
      be instantiated.  We need an Either because it might be instantiated
      freely: see Note [InstTypes: instantiating types] in InstEnv.
      
      (This might be a pattern we want to use elsewhere too.)
      2c8701fb
  32. 04 May, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Fix the pruning of dead case alternatives · 19e7eb57
      simonpj@microsoft.com authored
      This fixes Trac #1251; test case is gadt/CasePrune
      
      GHC was being over-eager about pruning dead alternatives from case
      expressions, and that led to a crash because the case expression 
      ended up with no alternatives at all!
      
      See the long comments Note [Pruning dead case alternatives] in Unify.
      19e7eb57
    • simonpj@microsoft.com's avatar
      isDataTyCon should be False for all type families, even data type families · 71d2bf92
      simonpj@microsoft.com authored
      isDataTyCon advertises that it's true of "data types that are
      definitely represented by heap-allocated constructors.  These are
      srcutinised by Core-level @case@ expressions, and they get info tables
      allocated for them."
      
      Type-family TyCons never have this property, not even data type families.
      It's the *instance* TyCons that do.
      
      I hope that this change does not break anything that somehow relied
      on the old (wrong) semantics.
      71d2bf92
  33. 02 May, 2007 1 commit