1. 20 Sep, 2008 1 commit
  2. 23 Sep, 2008 2 commits
  3. 22 Sep, 2008 3 commits
  4. 20 Sep, 2008 6 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #2597 (first bug): correct type checking for empty list · 5d786b6a
      simonpj@microsoft.com authored
      The GHC front end never generates (ExplicitList []), but TH can.
      This patch makes the typechecker robust to such programs.
    • simonpj@microsoft.com's avatar
      Fix Trac #2597 (second bug): complain about an empty DoE block · 6fa448e4
      simonpj@microsoft.com authored
      When converting an empty do-block from TH syntax to HsSyn,
      complain rather than crashing.
    • Ian Lynagh's avatar
      Update dependencies · f23f0af4
      Ian Lynagh authored
    • Ian Lynagh's avatar
      Fix building with GHC 6.6 · e5e6f6a1
      Ian Lynagh authored
    • Ian Lynagh's avatar
      Remove fno-method-sharing from the list of static flags · e6ab8ea2
      Ian Lynagh authored
      It is now a dynamic flag
    • simonpj@microsoft.com's avatar
      Tidy up the treatment of dead binders · 7e8cba32
      simonpj@microsoft.com authored
      This patch does a lot of tidying up of the way that dead variables are
      handled in Core.  Just the sort of thing to do on an aeroplane.
      * The tricky "binder-swap" optimisation is moved from the Simplifier
        to the Occurrence Analyser.  See Note [Binder swap] in OccurAnal.
        This is really a nice change.  It should reduce the number of
        simplifier iteratoins (slightly perhaps).  And it means that
        we can be much less pessimistic about zapping occurrence info
        on binders in a case expression.  
      * For example:
      	case x of y { (a,b) -> e }
        Previously, each time around, even if y,a,b were all dead, the
        Simplifier would pessimistically zap their OccInfo, so that we
        can't see they are dead any more.  As a result virtually no 
        case expression ended up with dead binders.  This wasn't Bad
        in itself, but it always felt wrong.
      * I added a check to CoreLint to check that a dead binder really
        isn't used.  That showed up a couple of bugs in CSE. (Only in
        this sense -- they didn't really matter.)
      * I've changed the PprCore printer to print "_" for a dead variable.
        (Use -dppr-debug to see it again.)  This reduces clutter quite a
        bit, and of course it's much more useful with the above change.
      * Another benefit of the binder-swap change is that I could get rid of
        the Simplifier hack (working, but hacky) in which the InScopeSet was
        used to map a variable to a *different* variable. That allowed me
        to remove VarEnv.modifyInScopeSet, and to simplify lookupInScopeSet
        so that it doesn't look for a fixpoint.  This fixes no bugs, but 
        is a useful cleanup.
      * Roman pointed out that Id.mkWildId is jolly dangerous, because
        of its fixed unique.  So I've 
           - localied it to MkCore, where it is private (not exported)
           - renamed it to 'mkWildBinder' to stress that you should only
             use it at binding sites, unless you really know what you are
           - provided a function MkCore.mkWildCase that emodies the most
             common use of mkWildId, and use that elsewhere
         So things are much better
      * A knock-on change is that I found a common pattern of localising
        a potentially global Id, and made a function for it: Id.localiseId
  5. 19 Sep, 2008 11 commits
  6. 18 Sep, 2008 3 commits
  7. 18 Apr, 2008 1 commit
  8. 18 Sep, 2008 10 commits
  9. 17 Sep, 2008 3 commits
    • simonpj@microsoft.com's avatar
      Fix nasty infelicity: do not short-cut empty substitution in the simplifier · 3b896bc3
      simonpj@microsoft.com authored
      I was perplexed about why an arity-related WARN was tripping. It took 
      me _day_ (sigh) to find that it was because SimplEnv.substExpr was taking
      a short cut when the substitution was empty, thereby not subsituting for
      Ids in scope, which must be done (CoreSubst Note [Extending the Subst]).
      The fix is a matter of deleting the "optimisation".  Same with
      CoreSubst.substSpec, although I don't know if that actually caused a
    • simonpj@microsoft.com's avatar
      Avoid arity reduction when doing eta-reduce · 0ac253aa
      simonpj@microsoft.com authored
      We like things with high arity, so when doing eta reduction
      it's probably a good idea to avoid reducing arity.
    • simonpj@microsoft.com's avatar
      Add extra WARN test · a211dd24
      simonpj@microsoft.com authored
      This warning tests that the arity of a function does not decrease.
      And that it's at least as great as the strictness signature.
      Failing this test isn't a disater, but it's distinctly odd and 
      usually indicates that not enough information is getting propagated
      around, and hence you may get more simplifier iterations.