1. 15 Sep, 2008 1 commit
  2. 14 Sep, 2008 1 commit
  3. 13 Sep, 2008 5 commits
  4. 12 Sep, 2008 17 commits
  5. 11 Sep, 2008 5 commits
  6. 10 Sep, 2008 1 commit
  7. 09 Sep, 2008 3 commits
  8. 10 Sep, 2008 7 commits
    • simonpj@microsoft.com's avatar
      7aac567c
    • simonpj@microsoft.com's avatar
      Check the *right* set of type variables for escape! · 62ee856c
      simonpj@microsoft.com authored
      I did the wrong checkSigTyVars, which (happily) triggered an ASSERT
      failure.  This should fix it.
      62ee856c
    • simonpj@microsoft.com's avatar
      More refactoring of instance declarations (fixes Trac #2572) · aaed05e8
      simonpj@microsoft.com authored
      In refactoring instance declarations I'd taken a short cut over
      scoped type variables, but it wasn't right as #2572 shows.
      
      Fixing it required a significant chunk of further refactoring,
      alas. But it's done!  Quite tidily as it turns out.
      
      The main issue is that when typechecking a default method, we
      need two sets of type variables in scope
      	class C a where
         	  op :: forall b. ...
      	  op = e
      In 'e', *both* 'a' and 'b' are in scope.  But the type of the
      default method has a nested flavour
      	op :: forall a. C a => forall b. ....
      and our normal scoping mechanisms don't bring 'b' into scope.
      (And probably shouldn't.)  
      
      Solution (which is done for instance methods too) is to use
      a local defintion, like this:
      
        $dmop :: forall a. C a => forall b. ....
        $dmop a d = let 
                       op :: forall b. ...
                       op = e
                    in op
      
      and now the scoping works out.  I hope I have now see the
      last of this code for a bit!
      aaed05e8
    • simonpj@microsoft.com's avatar
      Fix Trac #2581: inlining of record selectors · 112ad197
      simonpj@microsoft.com authored
      Bryan discovered that a non-trivial record selector (non-trivial in 
      the sense that it has to reconstruct the result value because of
      UNPACK directives) weren't being inlined.  The reason was that the
      unfolding generated by MkId.mRecordSelId was never being optimised
      *at all*, and hence looked big, and hence wasn't inlined.
      
      (The out-of-line version *is* put into the code of the module
      and *is* optimised, which made this bug pretty puzzling.  But the
      unfolding inside the record-selector-Id itself, which is a GlobalId
      and hence does not get its inlining updated like LocalIds, was
      big and fat.)
      
      Solution: I wrote a very simple optimiser, CoreUnfold.simplOptExpr,
      which does enough optimisation to solve this particular problem.
      It's short, simple, and will be useful in other contexts.
      112ad197
    • simonpj@microsoft.com's avatar
      911a3e09
    • simonpj@microsoft.com's avatar
      Fix the zonking of HsWrappers · a62561f7
      simonpj@microsoft.com authored
      HsWrappers are horribly inconsistent at the moment. I intended that
        WpLam, WpApp     are for evidence abstraction/application
        WpTyLam, WpTyApp are for type abstraction/application
      
      But when we zonk (WpApp co), where co is a coercion variable, we 
      get a *coercion* not a coercion *variable*.   So for now I'm making
      it into a WpTyApp, which the desugarer handles perfectly well.
      
      (I'd forgotten to zonk it properly at all; that is the bug that 
      this patch fixes.)
      a62561f7
    • simonpj@microsoft.com's avatar
      Add newDictOcc, newDictOccs · b7f052c4
      simonpj@microsoft.com authored
      b7f052c4