1. 04 Dec, 2007 1 commit
    • mnislaih's avatar
      Teach :print to follow references (STRefs and IORefs) · f4d6209d
      mnislaih authored
      Prelude Data.IORef> :p l
      l = (_t4::Maybe Integer) : (_t5::[Maybe Integer])
      Prelude Data.IORef> p <- newIORef l
      Prelude Data.IORef> :p p
      p = GHC.IOBase.IORef (GHC.STRef.STRef {((_t6::Maybe Integer) :
                                              (_t7::[Maybe Integer]))})
      Prelude Data.IORef> :sp p
      p = GHC.IOBase.IORef (GHC.STRef.STRef {(_ : _)})
      I used braces to denote the contents of a reference.
      Perhaps there is a more appropriate notation?
  2. 02 Dec, 2007 1 commit
  3. 04 Dec, 2007 7 commits
  4. 03 Dec, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Improve eta reduction, to reduce Simplifier iterations · a5f2ab64
      simonpj@microsoft.com authored
      I finally got around to investigating why the Simplifier was sometimes
      iterating so often.  There's a nice example in Text.ParserCombinators.ReadPrec,
      which produced:
      NOTE: Simplifier still going after 3 iterations; bailing out.  Size = 339
      NOTE: Simplifier still going after 3 iterations; bailing out.  Size = 339
      NOTE: Simplifier still going after 3 iterations; bailing out.  Size = 339
      No progress is being made.  It turned out that an interaction between
      eta-expansion, casts, and eta reduction was responsible. The change is
      small and simple, in SimplUtils.mkLam: do not require the body to be
      a Lam when floating the cast outwards.  
      I also discovered a missing side condition in the same equation, so fixing
      that is good too.  Now there is no loop when compiling ReadPrec.
      Should do a full nofib run though.
  5. 02 Dec, 2007 1 commit
  6. 28 Nov, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Improve pretty-printing for Insts · 12d8935e
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Reorganise TcSimplify (again); FIX Trac #1919 · 06f6f35d
      simonpj@microsoft.com authored
      This was a bit tricky.  We had a "given" dict like (d7:Eq a); then it got
      supplied to reduceImplication, which did some zonking, and emerged with
      a "needed given" (d7:Eq Int). That got everything confused.
      I found a way to simplify matters significantly.  Now reduceContext
      	- first deals with methods/literals/dictionaries
      	- then deals with implications
      Separating things in this way not only made the bug go away, but
      eliminated the need for the recently-added "needed-givens" results returned
      by checkLoop.  Hurrah.
      It's still a swamp.  But it's a bit better.
  7. 30 Nov, 2007 2 commits
  8. 28 Nov, 2007 4 commits
  9. 22 Nov, 2007 1 commit
  10. 27 Nov, 2007 5 commits
  11. 26 Nov, 2007 6 commits
  12. 25 Nov, 2007 5 commits
  13. 24 Nov, 2007 4 commits