1. 29 Nov, 2009 2 commits
  2. 27 Nov, 2009 2 commits
  3. 18 Sep, 2009 1 commit
  4. 25 Nov, 2009 7 commits
  5. 24 Nov, 2009 1 commit
  6. 06 Nov, 2009 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      * Refactor CLabel.RtsLabel to CLabel.CmmLabel · a02e7f40
      Ben.Lippmeier@anu.edu.au authored
      The type of the CmmLabel ctor is now
        CmmLabel :: PackageId -> FastString -> CmmLabelInfo -> CLabel
       - When you construct a CmmLabel you have to explicitly say what
         package it is in. Many of these will just use rtsPackageId, but
         I've left it this way to remind people not to pretend labels are
         in the RTS package when they're not. 
       - When parsing a Cmm file, labels that are not defined in the 
         current file are assumed to be in the RTS package. 
         Labels imported like
            import label
         are assumed to be in a generic "foreign" package, which is different
         from the current one.
         Labels imported like
            import "package-name" label
         are marked as coming from the named package.
         This last one is needed for the integer-gmp library as we want to
         refer to labels that are not in the same compilation unit, but
         are in the same non-rts package.
         This should help remove the nasty #ifdef __PIC__ stuff from
  7. 29 Oct, 2009 1 commit
  8. 28 Oct, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Add 'rec' to stmts in a 'do', and deprecate 'mdo' · f04dead9
      simonpj@microsoft.com authored
      The change is this (see Trac #2798).  Instead of writing
        mdo { a <- getChar
            ; b <- f c
            ; c <- g b
            ; putChar c
            ; return b }
      you would write
        do { a <- getChar
           ; rec { b <- f c
                 ; c <- g b }
           ; putChar c
           ; return b }
      That is, 
        * 'mdo' is eliminated 
        * 'rec' is added, which groups a bunch of statements
          into a single recursive statement
      This 'rec' thing is already present for the arrow notation, so it  
      makes the two more uniform.  Moreover, 'rec' lets you say more
      precisely where the recursion is (if you want to), whereas 'mdo' just
      says "there's recursion here somewhere".  Lastly, all this works with
      rebindable syntax (which mdo does not).
      Currently 'mdo' is enabled by -XRecursiveDo.  So we now deprecate this
      flag, with another flag -XDoRec to enable the 'rec' keyword.
      Implementation notes:
        * Some changes in Lexer.x
        * All uses of RecStmt now use record syntax
      I'm still not really happy with the "rec_ids" and "later_ids" in the
      RecStmt constructor, but I don't dare change it without consulting Ross
      about the consequences for arrow syntax.
  9. 07 Oct, 2009 1 commit
  10. 10 Sep, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Three improvements to Template Haskell (fixes #3467) · 1e436f2b
      simonpj@microsoft.com authored
      This patch implements three significant improvements to Template Haskell.
      Declaration-level splices with no "$" 
      This change simply allows you to omit the "$(...)" wrapper for 
      declaration-level TH splices.  An expression all by itself is
      not legal, so we now treat it as a TH splice.  Thus you can now
      	data T = T1 | T2
       	deriveMyStuff ''T
      where deriveMyStuff :: Name -> Q [Dec]
      This makes a much nicer interface for clients of libraries that use
      TH: no scary $(deriveMyStuff ''T).
      Nested top-level splices
      Previously TH would reject this, saying that splices cannot be nested:
      	f x = $(g $(h 'x))
      But there is no reason for this not to work.  First $(h 'x) is run,
      yielding code <blah> that is spliced instead of the $(h 'x). Then (g
      <blah>) is typechecked and run, yielding code that replaces the
      $(g ...) splice.  
      So this simply lifts the restriction.
      Fix Trac #3467: non-top-level type splices
      It appears that when I added the ability to splice types in TH
      programs, I failed to pay attention to non-top-level splices -- that
      is, splices inside quotatation brackets.  
      This patch fixes the problem.  I had to modify HsType, so there's a
      knock-on change to Haddock.
      Its seems that a lot of lines of code has changed, but almost all the
      new lines are comments!
      General tidying up
      As a result of thinking all this out I re-jigged the data type ThStage,
      which had far too many values before.  And I wrote a nice state transition
      diagram to make it all precise; 
         see Note [Template Haskell state diagram] in TcSplice
      Lots more refactoring in TcSplice, resulting in significantly less code.
      (A few more lines, but actually less code -- the rest is comments.)
      I think the result is significantly cleaner.
  11. 05 Sep, 2009 1 commit
  12. 27 Jul, 2009 1 commit
  13. 25 Jul, 2009 1 commit
  14. 24 Jul, 2009 1 commit
  15. 17 Jul, 2009 1 commit
  16. 09 Jul, 2009 2 commits
  17. 02 Jul, 2009 1 commit
  18. 09 Jun, 2009 1 commit
  19. 11 Jun, 2009 1 commit
  20. 20 May, 2009 1 commit
  21. 14 May, 2009 1 commit
  22. 13 May, 2009 1 commit
  23. 24 Apr, 2009 1 commit
  24. 09 Apr, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #3155: better error message when -XRankNTypes is omitted · 6c06fdc7
      simonpj@microsoft.com authored
      This patch sligtly re-adjusts the way in which the syntax of types 
      is handled:
       * In the lexer, '.' and '*' are always accepted in types
         (previously it was conditional).  This things can't mean
         anything else in H98, which is the only reason for doing things
         conditionally in the lexer.
       * As a result '.' in types is never treated as an operator.
         Instead, lacking a 'forall' keyword, it turns into a plain parse error.
       * Test for -XKindSignatures in the renamer when processing
           a) type variable bindings
           b) types with sigs (ty :: kind-sig)
       * Make -XKindSignatures be implied by -XTypeFamilies 
         Previously this was buried in the conditonal lexing of '*'
  25. 18 Mar, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Add the notion of "constructor-like" Ids for rule-matching · 4bc25e8c
      simonpj@microsoft.com authored
      This patch adds an optional CONLIKE modifier to INLINE/NOINLINE pragmas, 
         {-# NOINLINE CONLIKE [1] f #-}
      The effect is to allow applications of 'f' to be expanded in a potential
      rule match.  Example
        {-# RULE "r/f" forall v. r (f v) = f (v+1) #-}
      Consider the term
           let x = f v in ..x...x...(r x)...
      Normally the (r x) would not match the rule, because GHC would be scared
      about duplicating the redex (f v). However the CONLIKE modifier says to
      treat 'f' like a constructor in this situation, and "look through" the
      unfolding for x.  So (r x) fires, yielding (f (v+1)).
      The main changes are:
        - Syntax
        - The inlinePragInfo field of an IdInfo has a RuleMatchInfo
          component, which records whether or not the Id is CONLIKE.
          Of course, this needs to be serialised in interface files too.
        - The occurrence analyser (OccAnal) and simplifier (Simplify) treat
          CONLIKE thing like constructors, by ANF-ing them
        - New function coreUtils.exprIsExpandable is like exprIsCheap, but
          additionally spots applications of CONLIKE functions
        - A CoreUnfolding has a field that caches exprIsExpandable
        - The rule matcher consults this field.  See 
          Note [Expanding variables] in Rules.lhs.
      On the way I fixed a lurking variable bug in the way variables are
      expanded.  See Note [Do not expand locally-bound variables] in
      Rule.lhs.  I also did a bit of reformatting and refactoring in
      Rules.lhs, so the module has more lines changed than are really
  26. 06 Mar, 2009 1 commit
  27. 13 Jan, 2009 1 commit
  28. 09 Dec, 2008 2 commits
  29. 08 Nov, 2008 2 commits