1. 04 Mar, 2010 1 commit
  2. 24 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Refactor CoreArity a bit · 0252f1a4
      simonpj@microsoft.com authored
      I was experimenting with making coercions opaque to
      arity.  I think this is ultimately the right thing to do
      but I've left the functionality unchanged for now.
      0252f1a4
  3. 22 Dec, 2009 1 commit
  4. 04 Jan, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Substantial improvements to coercion optimisation · b06d623b
      simonpj@microsoft.com authored
      The main purpose of this patch is to add a bunch of new rules
      to the coercion optimiser.  They are documented in the (revised)
      Appendix of the System FC paper.  
      
      Some code has moved about:
      
      - OptCoercion is now a separate module, mainly because it
        now uses tcMatchTy, which is defined in Unify, so OptCoercion
        must live higehr up in the hierarchy
      
      - Functions that manipulate Kinds has moved from 
        Type.lhs to Coercion.lhs.  Reason: the function typeKind
        now needs to call coercionKind.  And in any case, a Kind is
        a flavour of Type, so it builds on top of Type; indeed Coercions
        and Kinds are both flavours of Type.
      
        This change required fiddling with a number of imports, hence
        the one-line changes to otherwise-unrelated modules
      
      - The representation of CoTyCons in TyCon has changed.   Instead of
        an extensional representation (a kind checker) there is now an
        intensional representation (namely TyCon.CoTyConDesc).  This was
        needed for one of the new coercion optimisations.
      b06d623b
  5. 16 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Two improvements to optCoercion · 06481242
      simonpj@microsoft.com authored
      * Fix a bug that meant that 
           (right (inst (forall tv.co) ty)) 
        wasn't getting optimised.  This showed up in the
        compiled code for ByteCodeItbls
      
      * Add a substitution to optCoercion, so that it simultaneously
        substitutes and optimises.  Both call sites wanted this, and
        optCoercion itself can use it, so it seems a win all round.
      06481242
  6. 11 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Use full equality for CSE · 21eeb926
      simonpj@microsoft.com authored
      In CSE we were getting lots of apprarently-unequal expressions with
      the same hash code.  In fact they were perfectly equal -- but we were
      using a cheap-and-cheerful equality tests for CoreExpr that said False
      for any lambda expression!
      
      This patch adds a proper equality test for Core, with alpha-renaming.
      It's easy to do, and will avoid silly cases of CSE failing to fire.
      
      We should get less of this:
        WARNING: file compiler/simplCore/CSE.lhs line 326
        extendCSEnv: long list, length 18
      from a compiler built with -DDEBUG
      21eeb926
  7. 19 Nov, 2009 1 commit
  8. 12 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      A radical overhaul of the coercion infrastucture · cd0e2c0c
      simonpj@microsoft.com authored
      * Core Lint now does full checking of kinds and coercion terms
        which picks up kind errors in coercions that were previously
        simply not checked for
      
      * Coercion.lhs now provides optCoercion which optimises coercion
        terms.  It implements all of Dimitrios's rules
      
      * The constructors for coercion terms now make no attempt to be
        "smart"; instead we rely solely on the coercion optimiser
      
      * CoercionTyCons in TyCon.lhs always had a "custom" kinding rule
        (the coKindFun field of CoercionTyCon) but its type was not 
        clever enough to do both 
           (a) *figure out the result kind*, assuming the whole thing
               is well-kinded in the first place
           (b) *check* the kinds of everything, failing gracefully if
               they aren't right. 
        We need (b) for the new CoreLint stuff. The field now has type
              CoTyConKindChecker
        which does the job nicely.
      cd0e2c0c
  9. 06 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up coercions, and implement csel1, csel2, cselR · bcadca67
      simonpj@microsoft.com authored
      In preparation for implementing the PushC rule for coercion-swizzling
      in the Simplifier, I had to inmplement the three new decomposition
      operators for coercions, which I've called csel1, csel2, and cselR.
      
           co :: ((s1~t1) => r1) ~ ((s2~t2) => r2)
           ---------------------------------------
                    csel1 co :: s1~s2
      
      and similarly csel2, cselR.
      
      On the way I fixed the coercionKind function for types of form
                (s1~t2) => r2
      which currently are expressed as a forall type.  
      
      And I refactored quite a bit to help myself understand what is
      going on.
      bcadca67
  10. 28 Oct, 2009 1 commit
  11. 13 Aug, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3409: type synonyms that discard their arguments · 2d1262b6
      simonpj@microsoft.com authored
      Type synonyms that don't mention one of their type parameters on the 
      RHS are a pain in the neck.  This patch fixes a long-standing bug (that
      simply has not appeared before) in that exprType could return a type
      mentioning an existentially-quantified variable (in one of those ignored
      argument positions).
      
      See CoreUtils Note [Existential variables and silly type synonyms]
      
      The fix is not entirely beautiful, but it works, and is very localised.
      2d1262b6
  12. 05 Mar, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Finally fix Trac #3066 · d7b56eff
      simonpj@microsoft.com authored
      This is a fix to 
        Tue Mar  3 17:42:58 GMT 2009  simonpj@microsoft.com
          * Fix Trac #3066: checking argument types in foreign calls
      which I embarassingly got wrong.
      
      Have to be careful when expanding recursive newtypes.
      
      Pls merge.
      d7b56eff
  13. 31 Dec, 2008 1 commit
  14. 23 Sep, 2008 1 commit
  15. 09 Oct, 2008 1 commit
  16. 02 Oct, 2008 1 commit
  17. 15 Sep, 2008 1 commit
  18. 07 Sep, 2008 1 commit
  19. 05 Sep, 2008 1 commit
  20. 07 Aug, 2008 1 commit
  21. 31 Jul, 2008 1 commit
  22. 28 May, 2008 1 commit
    • Simon Marlow's avatar
      Use MD5 checksums for recompilation checking (fixes #1372, #1959) · 526c3af1
      Simon Marlow authored
      This is a much more robust way to do recompilation checking.  The idea
      is to create a fingerprint of the ABI of an interface, and track
      dependencies by recording the fingerprints of ABIs that a module
      depends on.  If any of those ABIs have changed, then we need to
      recompile.
      
      In bug #1372 we weren't recording dependencies on package modules,
      this patch fixes that by recording fingerprints of package modules
      that we depend on.  Within a package there is still fine-grained
      recompilation avoidance as before.
      
      We currently use MD5 for fingerprints, being a good compromise between
      efficiency and security.  We're not worried about attackers, but we
      are worried about accidental collisions.
      
      All the MD5 sums do make interface files a bit bigger, but compile
      times on the whole are about the same as before.  Recompilation
      avoidance should be a bit more accurate than in 6.8.2 due to fixing
      #1959, especially when using -O.
      526c3af1
  23. 12 Apr, 2008 1 commit
  24. 22 Apr, 2008 1 commit
  25. 21 Apr, 2008 1 commit
  26. 29 Mar, 2008 2 commits
  27. 15 Mar, 2008 2 commits
  28. 02 Feb, 2008 1 commit
  29. 26 Jan, 2008 1 commit
  30. 21 Dec, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Improve handling of newtypes (fixes Trac 1495) · 219f900f
      simonpj@microsoft.com authored
      In a few places we want to "look through" newtypes to get to the
      representation type.  But we need to be careful that  we don't fall 
      into an ininite loop with e.g.
      	newtype T = MkT T
      
      The old mechansim for doing this was to have a field nt_rep, inside 
      a newtype TyCon, that gave the "ultimate representation" of the type.
      But that failed for Trac 1495, which looked like this:
         newtype Fix a = Fix (a (Fix a))
         data I a = I a
      Then, expanding the type (Fix I) went on for ever.
      
      The right thing to do seems to be to check for loops when epxanding
      the *type*, rather than in the *tycon*.  This patch does that, 
      	- Removes nt_rep from TyCon
      	- Make Type.repType check for loops
      See Note [Expanding newtypes] in Type.lhs.
      
      At the same time I also fixed a bug for Roman, where newtypes were not
      being expanded properly in FamInstEnv.topNormaliseType.  This function
      and Type.repType share a common structure.
      
      
      	Ian, see if this merges easily to the branch
      	If not, I don't think it's essential to fix 6.8
      219f900f
  31. 13 Nov, 2007 1 commit
  32. 02 Oct, 2007 1 commit
  33. 19 Sep, 2007 1 commit
  34. 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
  35. 11 Sep, 2007 1 commit
  36. 10 Sep, 2007 1 commit
  37. 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
  38. 04 Sep, 2007 1 commit