1. 06 Nov, 2008 3 commits
  2. 05 Nov, 2008 3 commits
  3. 04 Nov, 2008 2 commits
  4. 24 Oct, 2008 2 commits
  5. 23 Oct, 2008 1 commit
  6. 03 Nov, 2008 1 commit
  7. 31 Oct, 2008 5 commits
  8. 28 Oct, 2008 3 commits
  9. 31 Oct, 2008 1 commit
  10. 30 Oct, 2008 3 commits
    • simonpj@microsoft.com's avatar
      Improve error reporting for non-rigid GADT matches · 259d5ea8
      simonpj@microsoft.com authored
      Following suggestions from users, this patch improves the error message
      when a GADT match needs a rigid type:
      
       tcfail172.hs:19:10:
           GADT pattern match in non-rigid context for `Nil'
      -      Solution: add a type signature
      +      Probable solution: add a type signature for `is_normal'
           In the pattern: Nil
           In the definition of `is_normal': is_normal Nil = True
      
      Now GHC tries to tell you what to give a type signature *for*.
      Thanks to Daniel Gorin and others for the suggestions.
      259d5ea8
    • simonpj@microsoft.com's avatar
      Add (a) CoreM monad, (b) new Annotations feature · 9bcd95ba
      simonpj@microsoft.com authored
      This patch, written by Max Bolingbroke,  does two things
      
      1.  It adds a new CoreM monad (defined in simplCore/CoreMonad),
          which is used as the top-level monad for all the Core-to-Core
          transformations (starting at SimplCore).  It supports
             * I/O (for debug printing)
             * Unique supply
             * Statistics gathering
             * Access to the HscEnv, RuleBase, Annotations, Module
          The patch therefore refactors the top "skin" of every Core-to-Core
          pass, but does not change their functionality.
      
      2.  It adds a completely new facility to GHC: Core "annotations".
          The idea is that you can say
             {#- ANN foo (Just "Hello") #-}
          which adds the annotation (Just "Hello") to the top level function
          foo.  These annotations can be looked up in any Core-to-Core pass,
          and are persisted into interface files.  (Hence a Core-to-Core pass
          can also query the annotations of imported things.)  Furthermore,
          a Core-to-Core pass can add new annotations (eg strictness info)
          of its own, which can be queried by importing modules.
      
      The design of the annotation system is somewhat in flux.  It's
      designed to work with the (upcoming) dynamic plug-ins mechanism,
      but is meanwhile independently useful.
      
      Do not merge to 6.10!  
      9bcd95ba
    • simonpj@microsoft.com's avatar
  11. 29 Oct, 2008 3 commits
    • simonpj@microsoft.com's avatar
      Change naming conventions for compiler-generated dictionaries and type functions · 3bf13c88
      simonpj@microsoft.com authored
      Up to now, the data constructor dictionary for class C as been called
      ":DC". But there is no reason for the colon to be at the front; indeed
      it confuses the (simple-minded) pretty-printer for types.  So this
      patch changes it to be "D:C".  This makes Core a lot easier to read.
      Having a colon in the middle ensures that it can't clash with a user-written
      data type.
      
      Similarly I changed
      
        T:C 	   Data type corresponding a class dictionary (was :TC)
        D:C	   Data constructor for class dictionary (was :DC)
      
        NTCo:T   Coercion mapping from a newtype T to its representation type
      		(was :CoT)
      
        TFCo:R   Coercion mapping from a data family to its respresentation type R
      		(was :CoFR)
      
        Rn:T     The n'th respresentation data type for a data type T
      		(was :RnT)
      
      
      Do not merge to 6.10.
      
      HEADS-UP: you'll need to recompile libraries from scratch.  
      
      ROMAN: you could do the same for OccName.mkVectTyConOcc etc, if you wanted.
      
      3bf13c88
    • simonpj@microsoft.com's avatar
      a854a0b9
    • simonpj@microsoft.com's avatar
      592b4048
  12. 28 Oct, 2008 2 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #2720: inlining and casts · c3fe0f36
      simonpj@microsoft.com authored
      The issue here is what happens when we have
      
      	(f |> co) x
      
      where f is itself marked INLINE.  We want callSiteInline to "see" 
      the fact that the function is applied, and hence have some incentive
      to inline.  I've done this by extending CoreUnfold.CallCtxt with 
      ValAppCtxt.  I think that should catch this case without messing up
      any of the others.
      c3fe0f36
    • simonpj@microsoft.com's avatar
      Clarify documentatoin · bc35c8ed
      simonpj@microsoft.com authored
      bc35c8ed
  13. 23 Oct, 2008 1 commit
  14. 07 Oct, 2008 1 commit
  15. 20 Sep, 2008 2 commits
  16. 28 Oct, 2008 6 commits
  17. 27 Oct, 2008 1 commit