1. 08 Feb, 2009 1 commit
  2. 07 Feb, 2009 1 commit
  3. 06 Feb, 2009 6 commits
  4. 05 Feb, 2009 1 commit
  5. 04 Feb, 2009 4 commits
  6. 05 Feb, 2009 1 commit
  7. 04 Feb, 2009 2 commits
  8. 03 Feb, 2009 5 commits
  9. 02 Feb, 2009 1 commit
  10. 23 Jan, 2009 3 commits
  11. 22 Jan, 2009 1 commit
  12. 04 Feb, 2009 7 commits
  13. 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.
  14. 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.
  15. 13 Jan, 2009 1 commit
  16. 03 Feb, 2009 1 commit
  17. 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.
  18. 23 Jan, 2009 1 commit
  19. 30 Jan, 2009 1 commit