1. 04 Feb, 2009 2 commits
  2. 05 Feb, 2009 1 commit
  3. 04 Feb, 2009 2 commits
  4. 03 Feb, 2009 5 commits
  5. 02 Feb, 2009 1 commit
  6. 23 Jan, 2009 3 commits
  7. 22 Jan, 2009 1 commit
  8. 04 Feb, 2009 7 commits
  9. 15 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Robustify lookupFamInstEnv, plus some refactoring · 027e6be2
      simonpj@microsoft.com authored
      This patch deals with the following remark
      
           Suppose we have
                  type family T a :: * -> *
                  type instance T Int = []
      
           and now we encounter the type (T Int Bool).  If we call
           lookupFamInstEnv on (T Int Bool) we'll fail, because T has arity 1.
           Indeed, I *think* it's a precondition of lookupFamInstEnv that the
           supplied types exactly match the arity of the type function.  But
           that precondition is neither stated, nor is there an assertion to
           check it.
      
      With this patch, lookupFamInstEnv can take "extra" type arguments in
      the over-saturated case, and does the Right Thing.
      
      There was a nearly-identical function lookupFamInstEnvUnify, which
      required the precisely analogous change, so I took the opportunity 
      to combine the two into one function, so that bugs can be fixed in one
      place.  This was a bit harder than I expected, but I think the result
      is ok.  The conflict-decision function moves from FamInst to FamInstEnv.
      Net lines code decreases, although there are more comments.
      
      
      027e6be2
  10. 14 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Robustify lookupFamInstEnv · 27759873
      simonpj@microsoft.com authored
      Suppose we have
              type family T a :: * -> *
              type instance T Int = []
      
      and now we encounter the type (T Int Bool).  That is perfectly
      fine, even though T is over-saturated here.
      
      This patch makes lookupFamInstEnv robust to such over-saturation.
      Previously one caller (TcTyFuns.tcUnfoldSynFamInst) dealt with
      the over-saturation case, but the others did not. It's better
      to desl with the issue at the root, in lookupFamInstEnv itself.
      27759873
  11. 13 Jan, 2009 1 commit
  12. 03 Feb, 2009 1 commit
  13. 02 Feb, 2009 1 commit
    • Simon Marlow's avatar
      Optimise writing out the .s file · 6ba3d614
      Simon Marlow authored
      I noticed while working on the new IO library that GHC was writing out
      the .s file in lots of little chunks.  It turns out that this is a
      result of using multiple printDocs to avoid space leaks in the NCG,
      where each printDoc is finishing up with an hFlush.  
      
      What's worse, is that this makes poor use of the optimisation inside
      printDoc that uses its own buffering to avoid hitting the Handle all
      the time.
      
      So I hacked around this by making the buffering optimisation inside
      Pretty visible from the outside, for use in the NCG.  The changes are
      quite small.
      6ba3d614
  14. 23 Jan, 2009 1 commit
  15. 30 Jan, 2009 2 commits
  16. 02 Feb, 2009 2 commits
  17. 30 Jan, 2009 1 commit
  18. 01 Feb, 2009 1 commit
  19. 30 Jan, 2009 2 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #2985: generating superclasses and recursive dictionaries · c04a5fe3
      simonpj@microsoft.com authored
      The Note [Recursive instances and superclases] explains the subtle
      issues to do with generating the bindings for superclasses when
      we compile an instance declaration, at least if we want to do the
      clever "recursive superclass" idea from the SYB3 paper.
      
      The old implementation of tcSimplifySuperClasses stumbled when
      type equalities entered the picture (details in the Note); this
      patch fixes the problem using a slightly hacky trick.  When we
      re-engineer the constraint solver we'll want to keep an eye on 
      this.
      
      Probably worth merging to the 6.10 branch.
      
      c04a5fe3
    • simonpj@microsoft.com's avatar
      White space only · 6a104dcf
      simonpj@microsoft.com authored
      6a104dcf
  20. 29 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Two more wibbles to CorePrep (fixes HTTP package and DPH) · 6af98b2f
      simonpj@microsoft.com authored
      Ensuring that 
        a) lambdas show up only on the RHSs of binding after CorePrep
        b) the arity of a binding exactly matches the maifest lambdas
      is surprisingly tricky.
      
      I got it wrong (again) in my recent CorePrep shuffling, which broke
      packages HTTP and DPH.  This patch fixes both.
      6af98b2f
  21. 28 Jan, 2009 1 commit
  22. 27 Jan, 2009 2 commits