1. 02 Aug, 2013 1 commit
  2. 19 Jun, 2013 1 commit
  3. 21 Apr, 2013 1 commit
  4. 25 Jan, 2013 2 commits
    • Simon Peyton Jones's avatar
      Remove dead code · 9c661e07
      Simon Peyton Jones authored
      9c661e07
    • Simon Peyton Jones's avatar
      Refactor and improve the promotion inference · 09ff0e0d
      Simon Peyton Jones authored
      It should be the case that either an entire mutually recursive
      group of data type declarations can be promoted, or none of them.
      It's really odd to promote some data constructors of a type but
      not others. Eg
        data T a = T1 a | T2 Int
      Here T1 is sort-of-promotable but T2 isn't (becuase Int isn't
      promotable).
      
      This patch makes it all-or-nothing. At the same time I've made
      the TyCon point to its promoted cousin (via the tcPromoted field
      of an AlgTyCon), as well as vice versa (via the ty_con field of
      PromotedTyCon).
      
      The inference for the group is done in TcTyDecls, the same place
      that infers which data types are recursive, another global question.
      09ff0e0d
  5. 24 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Introduce CPR for sum types (Trac #5075) · d3b8991b
      Simon Peyton Jones authored
      The main payload of this patch is to extend CPR so that it
      detects when a function always returns a result constructed
      with the *same* constructor, even if the constructor comes from
      a sum type.  This doesn't matter very often, but it does improve
      some things (results below).
      
      Binary sizes increase a little bit, I think because there are more
      wrappers.  This with -split-objs.  Without split-ojbs binary sizes
      increased by 6% even for HelloWorld.hs.  It's hard to see exactly why,
      but I think it was because System.Posix.Types.o got included in the
      linked binary, whereas it didn't before.
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
                fluid          +1.8%     -0.3%      0.01      0.01     +0.0%
                  tak          +2.2%     -0.2%      0.02      0.02     +0.0%
                 ansi          +1.7%     -0.3%      0.00      0.00     +0.0%
            cacheprof          +1.6%     -0.3%     +0.6%     +0.5%     +1.4%
              parstof          +1.4%     -4.4%      0.00      0.00     +0.0%
              reptile          +2.0%     +0.3%      0.02      0.02     +0.0%
      ----------------------------------------------------------------------
                  Min          +1.1%     -4.4%     -4.7%     -4.7%    -15.0%
                  Max          +2.3%     +0.3%     +8.3%     +9.4%    +50.0%
       Geometric Mean          +1.9%     -0.1%     +0.6%     +0.7%     +0.3%
      
      Other things in this commit
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      * Got rid of the Lattice class in Demand
      
      * Refactored the way that products and newtypes are
        decomposed (no change in functionality)
      d3b8991b
  6. 18 Jan, 2013 1 commit
  7. 14 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Be willing to parse {-# UNPACK #-} without '!' · deec5b74
      Simon Peyton Jones authored
      This change gives a more helpful error message when the
      user says    data T = MkT {-# UNPACK #-} Int
      which should have a strictness '!' as well. Rather than
      just a parse error, we get
      
        T7562.hs:3:14: Warning:
          UNPACK pragma lacks '!' on the first argument of `MkT'
      
      Fixes Trac #7562
      deec5b74
  8. 23 Dec, 2012 1 commit
    • Simon Peyton Jones's avatar
      Make {-# UNPACK #-} work for type/data family invocations · 1ee1cd41
      Simon Peyton Jones authored
      This fixes most of Trac #3990.  Consider
        data family D a
        data instance D Double = CD Int Int
        data T = T {-# UNPACK #-} !(D Double)
      Then we want the (D Double unpacked).
      
      To do this we need to construct a suitable coercion, and it's much
      safer to record that coercion in the interface file, lest the in-scope
      instances differ somehow.  That in turn means elaborating the HsBang
      type to include a coercion.
      
      To do that I moved HsBang from BasicTypes to DataCon, which caused
      quite a few minor knock-on changes.
      
      Interface-file format has changed!
      
      Still to do: need to do knot-tying to allow instances to take effect
      within the same module.
      1ee1cd41
  9. 21 Dec, 2012 1 commit
  10. 19 Dec, 2012 2 commits
  11. 14 Dec, 2012 1 commit
    • Simon Peyton Jones's avatar
      Major refactoring of the way that UNPACK pragmas are handled · faa8ff40
      Simon Peyton Jones authored
      The situation was pretty dire.  The way in which data constructors
      were handled, notably the mapping between their *source* argument types
      and their *representation* argument types (after seq'ing and unpacking)
      was scattered in three different places, and hard to keep in sync.
      
      Now it is all in one place:
      
       * The dcRep field of a DataCon gives its representation,
         specified by a DataConRep
      
       * As well as having the wrapper, the DataConRep has a "boxer"
         of type DataConBoxer (defined in MkId for loopy reasons).
         The boxer used at a pattern match to reconstruct the source-level
         arguments from the rep-level bindings in the pattern match.
      
       * The unboxing in the wrapper and the boxing in the boxer are dual,
         and are now constructed together, by MkId.mkDataConRep. This is
         the key function of this change.
      
       * All the computeBoxingStrategy code in TcTyClsDcls disappears.
      
      Much nicer.
      
      There is a little bit of refactoring left to do; the strange
      deepSplitProductType functions are now called only in WwLib, so
      I moved them there, and I think they could be tidied up further.
      faa8ff40
  12. 05 Dec, 2012 1 commit
  13. 06 Nov, 2012 1 commit
  14. 19 Oct, 2012 1 commit
  15. 31 Aug, 2012 1 commit
  16. 12 Jun, 2012 1 commit
  17. 07 Jun, 2012 1 commit
  18. 15 May, 2012 1 commit
    • batterseapower's avatar
      Support code generation for unboxed-tuple function arguments · 09987de4
      batterseapower authored
      This is done by a 'unarisation' pre-pass at the STG level which
      translates away all (live) binders binding something of unboxed
      tuple type.
      
      This has the following knock-on effects:
        * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind)
        * Various relaxed type checks in typechecker, 'foreign import prim' etc
        * All case binders may be live at the Core level
      09987de4
  19. 05 Apr, 2012 1 commit
  20. 02 Mar, 2012 1 commit
    • Simon Peyton Jones's avatar
      Hurrah! This major commit adds support for scoped kind variables, · 3bf54e78
      Simon Peyton Jones authored
      which (finally) fills out the functionality of polymorphic kinds.
      It also fixes numerous bugs.
      
      Main changes are:
      
      Renaming stuff
      ~~~~~~~~~~~~~~
      * New type in HsTypes:
           data HsBndrSig sig = HsBSig sig [Name]
        which is used for type signatures in patterns, and kind signatures
        in types.  So when you say
             f (x :: [a]) = x ++ x
        or
             data T (f :: k -> *) (x :: *) = MkT (f x)
        the signatures in both cases are a HsBndrSig.
      
      * The [Name] in HsBndrSig records the variables bound by the
        pattern, that is 'a' in the first example, 'k' in the second,
        and nothing in the third.  The renamer initialises the field.
      
      * As a result I was able to get rid of
           RnHsSyn.extractHsTyNames :: LHsType Name -> NameSet
        and its friends altogether.  Deleted the entire module!
        This led to some knock-on refactoring; in particular the
        type renamer now returns the free variables just like the
        term renamer.
      
      Kind-checking types: mainly TcHsType
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      A major change is that instead of kind-checking types in two
      passes, we now do one. Under the old scheme, the first pass did
      kind-checking and (hackily) annotated the HsType with the
      inferred kinds; and the second pass desugared the HsType to a
      Type.  But now that we have kind variables inside types, the
      first pass (TcHsType.tc_hs_type) can go straight to Type, and
      zonking will squeeze out any kind unification variables later.
      
      This is much nicer, but it was much more fiddly than I had expected.
      
      The nastiest corner is this: it's very important that tc_hs_type
      uses lazy constructors to build the returned type. See
      Note [Zonking inside the knot] in TcHsType.
      
      Type-checking type and class declarations: mainly TcTyClsDecls
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      I did tons of refactoring in TcTyClsDecls.  Simpler and nicer now.
      
      Typechecking bindings: mainly TcBinds
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      I rejigged (yet again) the handling of type signatures in TcBinds.
      It's a bit simpler now.  The main change is that tcTySigs goes
      right through to a TcSigInfo in one step; previously it was split
      into two, part here and part later.
      
      Unsafe coercions
      ~~~~~~~~~~~~~~~~
      Usually equality coercions have exactly the same kind on both
      sides.  But we do allow an *unsafe* coercion between Int# and Bool,
      say, used in
          case error Bool "flah" of { True -> 3#; False -> 0# }
      -->
          (error Bool "flah") |> unsafeCoerce Bool Int#
      
      So what is the instantiation of (~#) here?
         unsafeCoerce Bool Int# :: (~#) ??? Bool Int#
      I'm using OpenKind here for now, but it's un-satisfying that
      the lhs and rhs of the ~ don't have precisely the same kind.
      
      More minor
      ~~~~~~~~~~
      * HsDecl.TySynonym has its free variables attached, which makes
        the cycle computation in TcTyDecls.mkSynEdges easier.
      
      * Fixed a nasty reversed-comparison bug in FamInstEnv:
        @@ -490,7 +490,7 @@ lookup_fam_inst_env' match_fun one_sided ie fam tys
           n_tys = length tys
           extra_tys = drop arity tys
           (match_tys, add_extra_tys)
      -       | arity > n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
      +       | arity < n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
              | otherwise     = (tys,            \res_tys -> res_tys)
      3bf54e78
  21. 16 Feb, 2012 1 commit
  22. 06 Feb, 2012 1 commit
  23. 16 Nov, 2011 1 commit
  24. 09 Nov, 2011 1 commit
  25. 04 Nov, 2011 1 commit
  26. 07 Sep, 2011 1 commit
  27. 06 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
      this patch adds a new kind Constraint such that:
      
        Show :: * -> Constraint
        (?x::Int) :: Constraint
        (Int ~ a) :: Constraint
      
      And you can write *any* type with kind Constraint to the left of (=>):
      even if that type is a type synonym, type variable, indexed type or so on.
      
      The following (somewhat related) changes are also made:
       1. We now box equality evidence. This is required because we want
          to give (Int ~ a) the *lifted* kind Constraint
       2. For similar reasons, implicit parameters can now only be of
          a lifted kind. (?x::Int#) => ty is now ruled out
       3. Implicit parameter constraints are now allowed in superclasses
          and instance contexts (this just falls out as OK with the new
          constraint solver)
      
      Internally the following major changes were made:
       1. There is now no PredTy in the Type data type. Instead
          GHC checks the kind of a type to figure out if it is a predicate
       2. There is now no AClass TyThing: we represent classes as TyThings
          just as a ATyCon (classes had TyCons anyway)
       3. What used to be (~) is now pretty-printed as (~#). The box
          constructor EqBox :: (a ~# b) -> (a ~ b)
       4. The type LCoercion is used internally in the constraint solver
          and type checker to represent coercions with free variables
          of type (a ~ b) rather than (a ~# b)
      9729fe7c
  28. 12 Jul, 2011 1 commit
  29. 12 May, 2011 1 commit
    • Simon Peyton Jones's avatar
      The final batch of changes for the new coercion representation · c8c2f6bb
      Simon Peyton Jones authored
      * Fix bugs in the packing and unpacking of data
        constructors with equality predicates in their types
      
      * Remove PredCo altogether; instead, coercions between predicated
        types (like  (Eq a, [a]~b) => blah) are treated as if they
        were precisely their underlying representation type
             Eq a -> ((~) [a] b) -> blah
        in this case
      
      * Similarly, Type.coreView no longer treats equality
        predciates specially.
      
      * Implement the cast-of-coercion optimisation in
        Simplify.simplCoercionF
      
      Numerous other small bug-fixes and refactorings.
      
      Annoyingly, OptCoercion had Windows line endings, and this
      patch switches to Unix, so it looks as if every line has changed.
      c8c2f6bb
  30. 04 May, 2011 1 commit
  31. 20 Apr, 2011 1 commit
  32. 19 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      This BIG PATCH contains most of the work for the New Coercion Representation · fdf86568
      Simon Peyton Jones authored
      See the paper "Practical aspects of evidence based compilation in System FC"
      
      * Coercion becomes a data type, distinct from Type
      
      * Coercions become value-level things, rather than type-level things,
        (although the value is zero bits wide, like the State token)
        A consequence is that a coerion abstraction increases the arity by 1
        (just like a dictionary abstraction)
      
      * There is a new constructor in CoreExpr, namely Coercion, to inject
        coercions into terms
      fdf86568
  33. 06 May, 2010 3 commits
  34. 04 May, 2010 1 commit
  35. 30 Mar, 2010 1 commit
  36. 06 Jul, 2009 1 commit