1. 02 Mar, 2015 1 commit
  2. 10 Feb, 2015 1 commit
  3. 02 Dec, 2014 2 commits
  4. 01 Dec, 2014 1 commit
  5. 28 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rename some of the functions in NameSet, to make the uniform with VarSet etc · 7460dafa
      Simon Peyton Jones authored
      For ages NameSet has used different names,
        eg.   addOneToNameSet   rather than    extendNameSet
              nameSetToList     rather than    nameSetElems
      etc.  Other set-like modules use uniform naming conventions.
      This patch makes NameSet follow suit.
      No change in behaviour; this is just renaming.
      I'm doing this just before the fork so that merging is easier.
  6. 20 Nov, 2014 2 commits
    • Jan Stolarek's avatar
      Kill trailing whitespace · e2f78036
      Jan Stolarek authored
    • Jan Stolarek's avatar
      Split SynTyCon to SynonymTyCon and FamilyTyCon · 696fc4ba
      Jan Stolarek authored
      This patch refactors internal representation of type synonyms and type families by splitting them into two separate data constructors of TyCon data type. The main motivation is is that some fields make sense only for type synonyms and some make sense only for type families. This will be even more true with the upcoming injective type families.
      There is also some refactoring of names to keep the naming constistent. And thus tc_kind field has become tyConKind and tc_roles has become tcRoles. Both changes are not visible from the outside of TyCon module.
      Updates haddock submodule
      Reviewers: simonpj
      Differential Revision: https://phabricator.haskell.org/D508
      GHC Trac Issues: #9812
  7. 31 Oct, 2014 1 commit
  8. 19 Sep, 2014 1 commit
    • Simon Peyton Jones's avatar
      Clean up Coercible handling, and interaction of data families with newtypes · 0aaf812e
      Simon Peyton Jones authored
      This patch fixes Trac #9580, in which the Coercible machinery succeeded
      even though the relevant data constructor was not in scope.
      As usual I got dragged into a raft of refactoring changes,
      all for the better.
      * Delete TcEvidence.coercionToTcCoercion (now unused)
      * Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst,
        and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon
        (They both return TcCoercions.)
      * tcInstNewTyConTF_maybe also gets more convenient type,
        which improves TcInteract.getCoercibleInst
      * Define FamInst.tcLookupDataFamInst, and use it in TcDeriv,
        (as well as in tcInstNewTyConTF_maybe)
      * Improve error report for Coercible errors, when data familes
        are involved  Another use of tcLookupDataFamInst
      * In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace
        local hacky code
      * Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal
        with eta-reduced newtypes, using
        (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX
      Some small refactoring of TcSMonad.matchFam.
  9. 31 Jul, 2014 2 commits
  10. 11 Jul, 2014 1 commit
  11. 15 May, 2014 2 commits
    • Simon Peyton Jones's avatar
      Refactoring around TyCon.isSynTyCon · 022f8750
      Simon Peyton Jones authored
      * Document isSynTyCon better
      * Add isTypeSyonymTyCon for regular H98 type synonyms
      * Use isTypeSynonymTyCon rather than isSynTyCon where
        the former is really intended
      All arose as part of a bug I introduced when fixing Trac #9102,
      thinking that isSynTyCon meant H98 type syononyms.
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
  12. 22 Nov, 2013 1 commit
  13. 20 Nov, 2013 1 commit
  14. 14 Nov, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Change the representation and move TcBuiltInSynFamily. · 19b8809c
      Iavor S. Diatchki authored
      The changes in more detail:
        * `TcBuiltInSynFamily` is now known as `BuiltinSynFamily` and
           lives in `CoAxiom`
        * `sfMatchFam` returns (CoAxiomRule, [Type], Type),
           which is enough to make Coersion or TcCoercion,
           depending on what what we need.
        * The rest of the compiler is updated to reflect these changes,
          most notably we can eliminate the cludge (XXX) in FamInstEnv
          and remove the lhs-boot file.
  15. 13 Nov, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Make type-level evaluation work with :kind! · b2fa2d41
      Iavor S. Diatchki authored
      The main change is to add a case to `reduceTyFamApp_maybe` to evaluate
      built-in type constructors (e.g., (+), (*), and friends).
      To avoid problems with recursive modules, I moved the definition of
      TcBuiltInSynFamily from `FamInst` to `FamInstEnv`.  I am still not sure if
      this is the right place.
      There is also a wibble that it'd be nice to fix:
      when we evaluate a built-in type function, using`sfMatchFam`, we get
      a `TcCoercion`.  However, `reduceTyFamApp_maybe` needs a `Corecion`.
      I couldn't find a nice way to convert between the two, so I resorted to
      a bit of hack (marked with `XXX`).
      The hack is that we happen to know that the built-in constructors for
      the type-nat functions always return coercions of shape `TcAxiomRuleCo`,
      with no assumptions, so it easy to convert `TcCoercion` to `Coercion`
      in this one case.  This is enough to make things work, but it is clearly
      a cludge.
  16. 18 Sep, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Change role annotation syntax. · f4046b50
      eir@cis.upenn.edu authored
      This fixes bugs #8185, #8234, and #8246. The new syntax is explained
      in the comments to #8185, appears in the "Roles" subsection of the
      manual, and on the [wiki:Roles] wiki page.
      This change also removes the ability for a role annotation on type
      synonyms, as noted in #8234.
  17. 13 Sep, 2013 1 commit
    • Iavor S. Diatchki's avatar
      Add support for evaluation of type-level natural numbers. · 1f77a534
      Iavor S. Diatchki authored
      This patch implements some simple evaluation of type-level expressions
      featuring natural numbers.  We can evaluate *concrete* expressions that
      use the built-in type families (+), (*), (^), and (<=?), declared in
      GHC.TypeLits.   We can also do some type inference involving these
      functions.  For example, if we encounter a constraint such as `(2 + x) ~ 5`
      we can infer that `x` must be 3.  Note, however, this is used only to
      resolve unification variables (i.e., as a form of a constraint improvement)
      and not to generate new facts.  This is similar to how functional
      dependencies work in GHC.
      The patch adds a new form of coercion, `AxiomRuleCo`, which makes use
      of a new form of axiom called `CoAxiomRule`.  This is the form of evidence
      generate when we solve a constraint, such as `(1 + 2) ~ 3`.
      The patch also adds support for built-in type-families, by adding a new
      form of TyCon rhs: `BuiltInSynFamTyCon`.  such built-in type-family
      constructors contain a record with functions that are used by the
      constraint solver to simplify and improve constraints involving the
      built-in function (see `TcInteract`).  The record in defined in `FamInst`.
      The type constructors and rules for evaluating the type-level functions
      are in a new module called `TcTypeNats`.
  18. 05 Aug, 2013 1 commit
  19. 02 Aug, 2013 1 commit
  20. 21 Jun, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Revise implementation of overlapping type family instances. · 569b2652
      eir@cis.upenn.edu authored
      This commit changes the syntax and story around overlapping type
      family instances. Before, we had "unbranched" instances and
      "branched" instances. Now, we have closed type families and
      open ones.
      The behavior of open families is completely unchanged. In particular,
      coincident overlap of open type family instances still works, despite
      emails to the contrary.
      A closed type family is declared like this:
      > type family F a where
      >   F Int = Bool
      >   F a   = Char
      The equations are tried in order, from top to bottom, subject to
      certain constraints, as described in the user manual. It is not
      allowed to declare an instance of a closed family.
  21. 06 Jun, 2013 1 commit
    • Simon Peyton Jones's avatar
      Add TyCon.checkRecTc, and use in in typeArity · a1a67b58
      Simon Peyton Jones authored
      This just formalises an abstraction we've been using anyway,
      namely to expand "recursive" TyCons until we see them twice.
      We weren't doing this in typeArity, and that inconsistency
      was leading to a subsequent ASSERT failure, when compiling
      Stream.hs, which has a newtype like this
         newtype Stream m a b = Stream (m (Either b (a, Stream m a b)))
  22. 01 Feb, 2013 1 commit
  23. 30 Jan, 2013 1 commit
  24. 25 Jan, 2013 1 commit
    • 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
      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
      The inference for the group is done in TcTyDecls, the same place
      that infers which data types are recursive, another global question.
  25. 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)
  26. 15 Jan, 2013 1 commit
  27. 22 Dec, 2012 1 commit
    • eir@cis.upenn.edu's avatar
      Implement overlapping type family instances. · 8366792e
      eir@cis.upenn.edu authored
      An ordered, overlapping type family instance is introduced by 'type
      where', followed by equations. See the new section in the user manual
      ( for details. The canonical example is Boolean equality at the
      type family Equals (a :: k) (b :: k) :: Bool
      type instance where
        Equals a a = True
        Equals a b = False
      A branched family instance, such as this one, checks its equations in
      and applies only the first the matches. As explained in the note
      checking within groups] in FamInstEnv.lhs, we must be careful not to
      say, (Equals Int b) to False, because b might later unify with Int.
      This commit includes all of the commits on the overlapping-tyfams
      branch. SPJ
      requested that I combine all my commits over the past several months
      into one
      monolithic commit. The following GHC repos are affected: ghc, testsuite,
      utils/haddock, libraries/template-haskell, and libraries/dph.
      Here are some details for the interested:
      - The definition of CoAxiom has been moved from TyCon.lhs to a
        new file CoAxiom.lhs. I made this decision because of the
        number of definitions necessary to support BranchList.
      - BranchList is a GADT whose type tracks whether it is a
        singleton list or not-necessarily-a-singleton-list. The reason
        I introduced this type is to increase static checking of places
        where GHC code assumes that a FamInst or CoAxiom is indeed a
        singleton. This assumption takes place roughly 10 times
        throughout the code. I was worried that a future change to GHC
        would invalidate the assumption, and GHC might subtly fail to
        do the right thing. By explicitly labeling CoAxioms and
        FamInsts as being Unbranched (singleton) or
        Branched (not-necessarily-singleton), we make this assumption
        explicit and checkable. Furthermore, to enforce the accuracy of
        this label, the list of branches of a CoAxiom or FamInst is
        stored using a BranchList, whose constructors constrain its
        type index appropriately.
      I think that the decision to use BranchList is probably the most
      controversial decision I made from a code design point of view.
      Although I provide conversions to/from ordinary lists, it is more
      efficient to use the brList... functions provided in CoAxiom than
      always to convert. The use of these functions does not wander far
      from the core CoAxiom/FamInst logic.
      BranchLists are motivated and explained in the note [Branched axioms] in
      - The CoAxiom type has changed significantly. You can see the new
        type in CoAxiom.lhs. It uses a CoAxBranch type to track
        branches of the CoAxiom. Correspondingly various functions
        producing and consuming CoAxioms had to change, including the
        binary layout of interface files.
      - To get branched axioms to work correctly, it is important to have a
        of type "apartness": two types are apart if they cannot unify, and no
        substitution of variables can ever get them to unify, even after type
        simplification. (This is different than the normal failure to unify
        of the type family bit.) This notion in encoded in tcApartTys, in
        Because apartness is finer-grained than unification, the tcUnifyTys
        calls tcApartTys.
      - CoreLinting axioms has been updated, both to reflect the new
        form of CoAxiom and to enforce the apartness rules of branch
        application. The formalization of the new rules is in
      - The FamInst type (in types/FamInstEnv.lhs) has changed
        significantly, paralleling the changes to CoAxiom. Of course,
        this forced minor changes in many files.
      - There are several new Notes in FamInstEnv.lhs, including one
        discussing confluent overlap and why we're not doing it.
      - lookupFamInstEnv, lookupFamInstEnvConflicts, and
        lookup_fam_inst_env' (the function that actually does the work)
        have all been more-or-less completely rewritten. There is a
        Note [lookup_fam_inst_env' implementation] describing the
        implementation. One of the changes that affects other files is
        to change the type of matches from a pair of (FamInst, [Type])
        to a new datatype (which now includes the index of the matching
        branch). This seemed a better design.
      - The TySynInstD constructor in Template Haskell was updated to
        use the new datatype TySynEqn. I also bumped the TH version
        number, requiring changes to DPH cabal files. (That's why the
        DPH repo has an overlapping-tyfams branch.)
      - As SPJ requested, I refactored some of the code in HsDecls:
       * splitting up TyDecl into SynDecl and DataDecl, correspondingly
         changing HsTyDefn to HsDataDefn (with only one constructor)
       * splitting FamInstD into TyFamInstD and DataFamInstD and
         splitting FamInstDecl into DataFamInstDecl and TyFamInstDecl
       * making the ClsInstD take a ClsInstDecl, for parallelism with
         InstDecl's other constructors
       * changing constructor TyFamily into FamDecl
       * creating a FamilyDecl type that stores the details for a family
         declaration; this is useful because FamilyDecls can appear in classes
         other decls cannot
       * restricting the associated types and associated type defaults for a
       * class
         to be the new, more restrictive types
       * splitting cid_fam_insts into cid_tyfam_insts and cid_datafam_insts,
         according to the new types
       * perhaps one or two more that I'm overlooking
      None of these changes has far-reaching implications.
      - The user manual, section, is updated to describe the new type
  28. 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.
  29. 07 Dec, 2012 1 commit
    • tibbe's avatar
      Add -funbox-strict-primitive-fields · 566920c7
      tibbe authored
      When enabled, this flag causes all strict fields which representation is
      smaller or equal to the size of a pointer to be unboxed.
  30. 05 Dec, 2012 1 commit
  31. 01 Dec, 2012 1 commit
    • eir@cis.upenn.edu's avatar
      Added GHC formalism to the GHC source tree. · 81b7e587
      eir@cis.upenn.edu authored
      As per a request from Simon PJ, I wrote up a formalism of the core
      language in GHC, System FC. The writeup lives in docs/core-spec.
      I also added comments to a number of files dealing with the core
      language reminding authors to update the formalism when updating the
      code. In the next commit will be a README file in docs/core-spec
      with more details of how to do this.
  32. 12 Nov, 2012 1 commit
    • Simon Marlow's avatar
      Remove OldCmm, convert backends to consume new Cmm · d92bd17f
      Simon Marlow authored
      This removes the OldCmm data type and the CmmCvt pass that converts
      new Cmm to OldCmm.  The backends (NCGs, LLVM and C) have all been
      converted to consume new Cmm.
      The main difference between the two data types is that conditional
      branches in new Cmm have both true/false successors, whereas in OldCmm
      the false case was a fallthrough.  To generate slightly better code we
      occasionally need to invert a conditional to ensure that the
      branch-not-taken becomes a fallthrough; this was previously done in
      CmmCvt, and it is now done in CmmContFlowOpt.
      We could go further and use the Hoopl Block representation for native
      code, which would mean that we could use Hoopl's postorderDfs and
      analyses for native code, but for now I've left it as is, using the
      old ListGraph representation for native code.
  33. 19 Oct, 2012 1 commit
  34. 18 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Make a start towards eta-rules and injective families · 58470fb7
      Simon Peyton Jones authored
      * Make Any into a type family (which it should always have been)
        This is to support the future introduction of eta rules for
        product types (see email on ghc-users title "PolyKind issue"
        early Sept 2012)
      * Add the *internal* data type support for
          (a) closed type families [so that you can't give
              type instance for 'Any']
          (b) injective type families [because Any is really
        This amounts to two boolean flags on the SynFamilyTyCon
        constructor of TyCon.SynTyConRhs.
      There is some knock-on effect, but all of a routine nature.
      It remains to offer source syntax for either closed or
      injective families.
  35. 16 Sep, 2012 2 commits