1. 18 Feb, 2021 1 commit
  2. 29 Oct, 2020 1 commit
    • Sylvain Henry's avatar
      Split GHC.Driver.Types · 0e9f6def
      Sylvain Henry authored
      I was working on making DynFlags stateless (#17957), especially by
      storing loaded plugins into HscEnv instead of DynFlags. It turned out to
      be complicated because HscEnv is in GHC.Driver.Types but LoadedPlugin
      isn't: it is in GHC.Driver.Plugins which depends on GHC.Driver.Types. I
      didn't feel like introducing yet another hs-boot file to break the loop.
      Additionally I remember that while we introduced the module hierarchy
      (#13009) we talked about splitting GHC.Driver.Types because it contained
      various unrelated types and functions, but we never executed. I didn't
      feel like making GHC.Driver.Types bigger with more unrelated Plugins
      related types, so finally I bit the bullet and split GHC.Driver.Types.
      As a consequence this patch moves a lot of things. I've tried to put
      them into appropriate modules but nothing is set in stone.
      Several other things moved to avoid loops.
      * Removed Binary instances from GHC.Utils.Binary for random compiler
      * Moved Typeable Binary instances into GHC.Utils.Binary.Typeable: they
        import a lot of things that users of GHC.Utils.Binary don't want to
        depend on.
      * put everything related to Units/Modules under GHC.Unit:
        GHC.Unit.Finder, GHC.Unit.Module.{ModGuts,ModIface,Deps,etc.}
      * Created several modules under GHC.Types: GHC.Types.Fixity, SourceText,
      * Split GHC.Utils.Error (into GHC.Types.Error)
      * Finally removed GHC.Driver.Types
      Note that this patch doesn't put loaded plugins into HscEnv. It's left
      for another patch.
      Bump haddock submodule
  3. 17 Jun, 2020 2 commits
    • Krzysztof Gogolewski's avatar
      Various performance improvements · 6cb84c46
      Krzysztof Gogolewski authored
      This implements several general performance improvements to GHC,
      to offset the effect of the linear types change.
      General optimisations:
      - Add a `coreFullView` function which iterates `coreView` on the
        head. This avoids making function recursive solely because the
        iterate `coreView` themselves. As a consequence, this functions can
        be inlined, and trigger case-of-known constructor (_e.g._
        `kindRep_maybe`, `isLiftedRuntimeRep`, `isMultiplicityTy`,
        `getTyVar_maybe`, `splitAppTy_maybe`, `splitFunType_maybe`,
        `tyConAppTyCon_maybe`). The common pattern about all these functions
        is that they are almost always used as views, and immediately
        consumed by a case expression. This commit also mark them asx `INLINE`.
      - In `subst_ty` add a special case for nullary `TyConApp`, which avoid
        allocations altogether.
      - Use `mkTyConApp` in `subst_ty` for the general `TyConApp`. This
        required quite a bit of module shuffling.
        case. `myTyConApp` enforces crucial sharing, which was lost during
        substitution. See also !2952 .
      - Make `subst_ty` stricter.
      - In `eqType` (specifically, in `nonDetCmpType`), add a special case,
        tested first, for the very common case of nullary `TyConApp`.
        `nonDetCmpType` has been made `INLINE` otherwise it is actually a
        regression. This is similar to the optimisations in !2952.
      Linear-type specific optimisations:
      - Use `tyConAppTyCon_maybe` instead of the more complex `eqType` in
        the definition of the pattern synonyms `One` and `Many`.
      - Break the `hs-boot` cycles between `Multiplicity.hs` and `Type.hs`:
        `Multiplicity` now import `Type` normally, rather than from the
        `hs-boot`. This way `tyConAppTyCon_maybe` can inline properly in the
        `One` and `Many` pattern synonyms.
      - Make `updateIdTypeAndMult` strict in its type and multiplicity
      - The `scaleIdBy` gets a specialised definition rather than being an
        alias to `scaleVarBy`
      - `splitFunTy_maybe` is given the type `Type -> Maybe (Mult, Type,
        Type)` instead of `Type -> Maybe (Scaled Type, Type)`
      - Remove the `MultMul` pattern synonym in favour of a view `isMultMul`
        because pattern synonyms appear not to inline well.
      - in `eqType`, in a `FunTy`, compare multiplicities last: they are
        almost always both `Many`, so it helps failing faster.
      - Cache `manyDataConTy` in `mkTyConApp`, to make sure that all the
        instances of `TyConApp ManyDataConTy []` are physically the same.
      This commit has been authored by
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Arnaud Spiwack
      Metric Decrease:
      Metric Increase:
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored
      This is the first step towards implementation of the linear types proposal
      It features
      * A language extension -XLinearTypes
      * Syntax for linear functions in the surface language
      * Linearity checking in Core Lint, enabled with -dlinear-core-lint
      * Core-to-core passes are mostly compatible with linearity
      * Fields in a data type can be linear or unrestricted; linear fields
        have multiplicity-polymorphic constructors.
        If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
      The following items are not yet supported:
      * a # m -> b syntax (only prefix FUN is supported for now)
      * Full multiplicity inference (multiplicities are really only checked)
      * Decent linearity error messages
      * Linear let, where, and case expressions in the surface language
        (each of these currently introduce the unrestricted variant)
      * Multiplicity-parametric fields
      * Syntax for annotating lambda-bound or let-bound with a multiplicity
      * Syntax for non-linear/multiple-field-multiplicity records
      * Linear projections for records with a single linear field
      * Linear pattern synonyms
      * Multiplicity coercions (test LinearPolyType)
      A high-level description can be found at
      Following the link above you will find a description of the changes made to Core.
      This commit has been authored by
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Matthew Pickering
      * Arnaud Spiwack
      With contributions from:
      * Mark Barbone
      * Alexander Vershilov
      Updates haddock submodule.
  4. 29 Mar, 2020 1 commit
  5. 17 Mar, 2020 1 commit
  6. 13 Nov, 2019 1 commit
    • Ben Gamari's avatar
      Ensure that coreView/tcView are able to inline · 2d4f9ad8
      Ben Gamari authored
      Previously an import cycle between Type and TyCoRep meant that several
      functions in TyCoRep ended up SOURCE import coreView. This is quite
      unfortunate as coreView is intended to be fused into a larger pattern
      match and not incur an extra call.
      Fix this with a bit of restructuring:
       * Move the functions in `TyCoRep` which depend upon things in `Type`
         into `Type`
       * Fold contents of `Kind` into `Type` and turn `Kind` into a simple
         wrapper re-exporting kind-ish things from `Type`
       * Clean up the redundant imports that popped up as a result
      Closes #17441.
      Metric Decrease:
  7. 31 Jul, 2019 1 commit
    • Ben Gamari's avatar
      Break up TyCoRep · 371dadfb
      Ben Gamari authored
      This breaks up the monstrous TyCoReps module into several new modules by
       * TyCoRep: Contains the `Coercion`, `Type`, and related type
         definitions and a few simple predicates but nothing further
       * TyCoPpr: Contains the the pretty-printer logic
       * TyCoFVs: Contains the free variable computations (and
         `tyConAppNeedsKindSig`, although I suspect this should change)
       * TyCoSubst: Contains the substitution logic for types and coercions
       * TyCoTidy: Contains the tidying logic for types
      While we are able to eliminate a good number of `SOURCE` imports (and
      make a few others smaller) with this change, we must introduce one new
      `hs-boot` file for `TyCoPpr` so that `TyCoRep` can define `Outputable`
      instances for the types it defines.
      Metric Increase:
  8. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      See Note [Function types] in TyCoRep.
      There are lots of consequences
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on ...
  9. 15 Sep, 2018 1 commit
    • Ningning Xie's avatar
      Coercion Quantification · ea5ade34
      Ningning Xie authored
      This patch corresponds to #15497.
      According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2,
       we would like to have coercion quantifications back. This will
      allow us to migrate (~#) to be homogeneous, instead of its current
      heterogeneous definition. This patch is (lots of) plumbing only. There
      should be no user-visible effects.
      An overview of changes:
      - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables,
      but only in *Core*. All relevant functions are updated accordingly.
      - Small changes that should be irrelevant to the main task:
          1. removed dead code `mkTransAppCo` in Coercion
          2. removed out-dated Note Computing a coercion kind and
             roles in Coercion
          3. Added `Eq4` in Note Respecting definitional equality in
             TyCoRep, and updated `mkCastTy` accordingly.
          4. Various updates and corrections of notes and typos.
      - Haddock submodule needs to be changed too.
      This work was completed mostly during Ningning Xi...
  10. 10 Jul, 2018 1 commit
    • Ningning Xie's avatar
      Refactor coercion rule · 55a3f855
      Ningning Xie authored
      The patch is an attempt on #15192.
      It defines a new coercion rule
       | GRefl Role Type MCoercion
      which correspondes to the typing rule
           t1 : k1
        GRefl r t1 MRefl: t1 ~r t1
           t1 : k1       co :: k1 ~ k2
        GRefl r t1 (MCo co) : t1 ~r t1 |> co
      MCoercion wraps a coercion, which might be reflexive (MRefl)
      or not (MCo co). To know more about MCoercion see #14975.
      We keep Refl ty as a special case for nominal reflexive coercions,
      naemly, Refl ty :: ty ~n ty.
      This commit is meant to be a general performance improvement,
      but there are a few regressions. See #15192, comment:13 for
      more information.
      Test Plan: ./validate
      Reviewers: bgamari, goldfire, simonpj
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15192
      Differential Revision: https://phabricator.haskell.org/D4747
  11. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
      Fixes #14066 #14749
      Test cases: dependent/should_compile/{T14066a,T14749},
  12. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored
      Here we consolidate the pretty-printing logic for types in IfaceType. We
      need IfaceType regardless and the printer for Type can be implemented in
      terms of that for IfaceType. See #11660.
      Note that this is very much a work-in-progress. Namely I still have yet
      to ponder how to ease the hs-boot file situation, still need to rip out
      more dead code, need to move some of the special cases for, e.g., `*` to
      the IfaceType printer, and need to get it to validate. That being said,
      it comes close to validating as-is.
      Test Plan: Validate
      Reviewers: goldfire, austin
      Subscribers: goldfire, thomie, simonpj
      Differential Revision: https://phabricator.haskell.org/D2528
      GHC Trac Issues: #11660
  13. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
        - tyConBinders :: [TyConBinder]
      The new data types look like this:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      Some smaller points
      * Nice new functions
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      There are a LOT of knock-on changes, but they are all routine.
      The Haddock submodule needs to be updated too
  14. 20 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Reduce use of instances in hs-boot files · 81aa3d1c
      Simon Peyton Jones authored
      Several things here
      * GHC no longer allows user-written Typeable instances,
        so remove them from hs-boot files.
      * Generally, reduce the use of instances in hs-boot files. They are
        hard to track.  Mainly this involves using pprType, pprKind etc
        instead of just ppr.  There were a lot of instances in hs-boot
        files that weren't needed at all.
      * Take TyThing out of Eq; it was used in exactly one place (in
        InteractiveEval), and equality is too big a hammer for that.
  15. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      This commit also contains a few performance improvements:
      * Short-cut equality checking of nullary type syns
      * Compare types before kinds in eqType
      * INLINE coreViewOneStarKind
      * Store tycon binders separately from kinds.
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      This commit updates the haddock submodule.
  16. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
       * The type of `*` is now `*`. No more `BOX`.
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
       * The new extension `TypeInType` turns on the new user-facing
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
       * The new features are still quite experimental and may be in flux.
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
       * TODO: Update user manual.
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
  17. 29 Oct, 2015 1 commit
    • Matthew Pickering's avatar
      Record pattern synonyms · 2a74a64e
      Matthew Pickering authored
      This patch implements an extension to pattern synonyms which allows user
      to specify pattern synonyms using record syntax. Doing so generates
      appropriate selectors and update functions.
      === Interaction with Duplicate Record Fields ===
      The implementation given here isn't quite as general as it could be with
      respect to the recently-introduced `DuplicateRecordFields` extension.
      Consider the following module:
          {-# LANGUAGE DuplicateRecordFields #-}
          {-# LANGUAGE PatternSynonyms #-}
          module Main where
          pattern S{a, b} = (a, b)
          pattern T{a}    = Just a
          main = do
            print S{ a = "fst", b = "snd" }
            print T{ a = "a" }
      In principle, this ought to work, because there is no ambiguity. But at
      the moment it leads to a "multiple declarations of a" error. The problem
      is that pattern synonym record selectors don't do the same name mangling
      as normal datatypes when DuplicateRecordFields is enabled. They could,
      but this would require some work to track the field label and selector
      name separately.
      In particular, we currently represent datatype selectors in the third
      component of AvailTC, but pattern synonym selectors are just represented
      as Avails (because they don't have a corresponding type constructor).
      Moreover, the GlobalRdrElt for a selector currently requires it to have
      a parent tycon.
      (example due to Adam Gundry)
      === Updating Explicitly Bidirectional Pattern Synonyms ===
      Consider the following
      pattern Silly{a} <- [a] where
        Silly a = [a, a]
      f1 = a [5] -- 5
      f2 = [5] {a = 6} -- currently [6,6]
      === Fixing Polymorphic Updates ===
      They were fixed by adding these two lines in `dsExpr`. This might break
      record updates but will be easy to fix.
      + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)
      - , pat_wrap = idHsWrapper }
      +, pat_wrap = req_wrap }
      === Mixed selectors error ===
      Note [Mixed Record Field Updates]
      Consider the following pattern synonym.
          data MyRec = MyRec { foo :: Int, qux :: String }
          pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}
      This allows updates such as the following
          updater :: MyRec -> MyRec
          updater a = a {f1 = 1 }
      It would also make sense to allow the following update (which we
          updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"
      This leads to confusing behaviour when the selectors in fact refer the
      same field.
          updater a = a {f1 = 1, foo = 2} ==? ???
      For this reason, we reject a mixture of pattern synonym and normal
      record selectors in the same update block. Although of course we still
      allow the following.
          updater a = (a {f1 = 1}) {foo = 2}
          > updater (MyRec 0 "str")
          MyRec 2 "str"
  18. 03 Sep, 2015 1 commit
  19. 18 Aug, 2015 1 commit
  20. 01 Dec, 2014 1 commit
  21. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 09015be8
      dreixel authored
      This big patch implements a kind-polymorphic core for GHC. The current
      implementation focuses on making sure that all kind-monomorphic programs still
      work in the new core; it is not yet guaranteed that kind-polymorphic programs
      (using the new -XPolyKinds flag) will work.
      For more information, see http://haskell.org/haskellwiki/GHC/Kinds
  22. 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)
  23. 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
  24. 21 Mar, 2007 1 commit
  25. 13 Oct, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add assertion checks for mkCoVar/mkTyVar · ac704fca
      simonpj@microsoft.com authored
      A type variable has a flag saying whether it is a *type* variable or
      a *coercion* variable.  This patch adds assertions to check the flag.
      And it adds fixes to places which were Wrong (and hence fired the
      Also removed isCoVar from Coercion, since it's done by Var.isCoVar.
  26. 23 Sep, 2006 1 commit
  27. 21 Sep, 2006 1 commit
  28. 04 Aug, 2006 1 commit
  29. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
  30. 27 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-27 10:44:00 by simonpj] · 508a505e
      simonpj authored
                Replace hi-boot files with hs-boot files
      This major commit completely re-organises the way that recursive modules
      are dealt with.
        * It should have NO EFFECT if you do not use recursive modules
        * It is a BREAKING CHANGE if you do
      ====== Warning: .hi-file format has changed, so if you are
      ======		updating into an existing HEAD build, you'll
      ======		need to make clean and re-make
      The details:  [documentation still to be done]
      * Recursive loops are now broken with Foo.hs-boot (or Foo.lhs-boot),
        not Foo.hi-boot
      * An hs-boot files is a proper source file.  It is compiled just like
        a regular Haskell source file:
      	ghc Foo.hs		generates Foo.hi, Foo.o
      	ghc Foo.hs-boot		generates Foo.hi-boot, Foo.o-boot
      * hs-boot files are precisely a subset of Haskell. In particular:
      	- they have the same import, export, and scoping rules
      	- errors (such as kind errors) in hs-boot files are checked
        You do *not* need to mention the "original" name of something in
        an hs-boot file, any more than you do in any other Haskell module.
      * The Foo.hi-boot file generated by compiling Foo.hs-boot is a machine-
        generated interface file, in precisely the same format as Foo.hi
      * When compiling Foo.hs, its exports are checked for compatibility with
        Foo.hi-boot (previously generated by compiling Foo.hs-boot)
      * The dependency analyser (ghc -M) knows about Foo.hs-boot files, and
        generates appropriate dependencies.  For regular source files it
      	Foo.o : Foo.hs
      	Foo.o : Baz.hi		-- Foo.hs imports Baz
      	Foo.o : Bog.hi-boot	-- Foo.hs source-imports Bog
        For a hs-boot file it generates similar dependencies
      	Bog.o-boot : Bog.hs-boot
      	Bog.o-boot : Nib.hi	-- Bog.hs-boto imports Nib
      * ghc -M is also enhanced to use the compilation manager dependency
        chasing, so that
      	ghc -M Main
        will usually do the job.  No need to enumerate all the source files.
      * The -c flag is no longer a "compiler mode". It simply means "omit the
        link step", and synonymous with -no-link.
  31. 02 Apr, 2004 1 commit
  32. 09 Oct, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-10-09 11:58:39 by simonpj] · 98688c6e
      simonpj authored
      		GHC heart/lung transplant
      This major commit changes the way that GHC deals with importing
      types and functions defined in other modules, during renaming and
      typechecking.  On the way I've changed or cleaned up numerous other
      things, including many that I probably fail to mention here.
      Major benefit: GHC should suck in many fewer interface files when
      compiling (esp with -O).  (You can see this with -ddump-rn-stats.)
      It's also some 1500 lines of code shorter than before.
      **	So expect bugs!  I can do a 3-stage bootstrap, and run
      **	the test suite, but you may be doing stuff I havn't tested.
      ** 	Don't update if you are relying on a working HEAD.
      In particular, (a) External Core and (b) GHCi are very little tested.
      	But please, please DO test this version!
      		Big things
      Interface files, version control, and importing declarations
      * There is a totally new data type for stuff that lives in interface files:
      	Original names			IfaceType.IfaceExtName
      	Types				IfaceType.IfaceType
      	Declarations (type,class,id)	IfaceSyn.IfaceDecl
      	Unfoldings			IfaceSyn.IfaceExpr
        (Previously we used HsSyn for type/class decls, and UfExpr for unfoldings.)
        The new data types are in iface/IfaceType and iface/IfaceSyn.  They are
        all instances of Binary, so they can be written into interface files.
        Previous engronkulation concering the binary instance of RdrName has
        gone away -- RdrName is not an instance of Binary any more.  Nor does
        Binary.lhs need to know about the ``current module'' which it used to,
        which made it specialised to GHC.
        A good feature of this is that the type checker for source code doesn't
        need to worry about the possibility that we might be typechecking interface
        file stuff.  Nor does it need to do renaming; we can typecheck direct from
        IfaceSyn, saving a whole pass (module TcIface)
      * Stuff from interface files is sucked in *lazily*, rather than being eagerly
        sucked in by the renamer. Instead, we use unsafeInterleaveIO to capture
        a thunk for the unfolding of an imported function (say).  If that unfolding
        is every pulled on, TcIface will scramble over the unfolding, which may
        in turn pull in the interface files of things mentioned in the unfolding.
        The External Package State is held in a mutable variable so that it
        can be side-effected by this lazy-sucking-in process (which may happen
        way later, e.g. when the simplifier runs).   In effect, the EPS is a kind
        of lazy memo table, filled in as we suck things in.  Or you could think
        of it as a global symbol table, populated on demand.
      * This lazy sucking is very cool, but it can lead to truly awful bugs. The
        intent is that updates to the symbol table happen atomically, but very bad
        things happen if you read the variable for the table, and then force a
        thunk which updates the table.  Updates can get lost that way. I regret
        this subtlety.
        One example of the way it showed up is that the top level of TidyPgm
        (which updates the global name cache) to be much more disciplined about
        those updates, since TidyPgm may itself force thunks which allocate new
      * Version numbering in interface files has changed completely, fixing
        one major bug with ghc --make.  Previously, the version of A.f changed
        only if A.f's type and unfolding was textually different.  That missed
        changes to things that A.f's unfolding mentions; which was fixed by
        eagerly sucking in all of those things, and listing them in the module's
        usage list.  But that didn't work with --make, because they might have
        been already sucked in.
        Now, A.f's version changes if anything reachable from A.f (via interface
        files) changes.  A module with unchanged source code needs recompiling
        only if the versions of any of its free variables changes. [This isn't
        quite right for dictionary functions and rules, which aren't mentioned
        explicitly in the source.  There are extensive comments in module MkIface,
        where all version-handling stuff is done.]
      * We don't need equality on HsDecls any more (because they aren't used in
        interface files).  Instead we have a specialised equality for IfaceSyn
        (eqIfDecl etc), which uses IfaceEq instead of Bool as its result type.
        See notes in IfaceSyn.
      * The horrid bit of the renamer that tried to predict what instance decls
        would be needed has gone entirely.  Instead, the type checker simply
        sucks in whatever instance decls it needs, when it needs them.  Easy!
        Similarly, no need for 'implicitModuleFVs' and 'implicitTemplateHaskellFVs'
        etc.  Hooray!
      Types and type checking
      * Kind-checking of types is far far tidier (new module TcHsTypes replaces
        the badly-named TcMonoType).  Strangely, this was one of my
        original goals, because the kind check for types is the Right Place to
        do type splicing, but it just didn't fit there before.
      * There's a new representation for newtypes in TypeRep.lhs.  Previously
        they were represented using "SourceTypes" which was a funny compromise.
        Now they have their own constructor in the Type datatype.  SourceType
        has turned back into PredType, which is what it used to be.
      * Instance decl overlap checking done lazily.  Consider
      	instance C Int b
      	instance C a Int
        These were rejected before as overlapping, because when seeking
        (C Int Int) one couldn't tell which to use.  But there's no problem when
        seeking (C Bool Int); it can only be the second.
        So instead of checking for overlap when adding a new instance declaration,
        we check for overlap when looking up an Inst.  If we find more than one
        matching instance, we see if any of the candidates dominates the others
        (in the sense of being a substitution instance of all the others);
        and only if not do we report an error.
      	     Medium things
      * The TcRn monad is generalised a bit further.  It's now based on utils/IOEnv.lhs,
        the IO monad with an environment.  The desugarer uses the monad too,
        so that anything it needs can get faulted in nicely.
      * Reduce the number of wired-in things; in particular Word and Integer
        are no longer wired in.  The latter required HsLit.HsInteger to get a
        Type argument.  The 'derivable type classes' data types (:+:, :*: etc)
        are not wired in any more either (see stuff about derivable type classes
      * The PersistentComilerState is now held in a mutable variable
        in the HscEnv.  Previously (a) it was passed to and then returned by
        many top-level functions, which was painful; (b) it was invariably
        accompanied by the HscEnv.  This change tidies up top-level plumbing
        without changing anything important.
      * Derivable type classes are treated much more like 'deriving' clauses.
        Previously, the Ids for the to/from functions lived inside the TyCon,
        but now the TyCon simply records their existence (with a simple boolean).
        Anyone who wants to use them must look them up in the environment.
        This in turn makes it easy to generate the to/from functions (done
        in types/Generics) using HsSyn (like TcGenDeriv for ordinary derivings)
        instead of CoreSyn, which in turn means that (a) we don't have to figure
        out all the type arguments etc; and (b) it'll be type-checked for us.
        Generally, the task of generating the code has become easier, which is
        good for Manuel, who wants to make it more sophisticated.
      * A Name now says what its "parent" is. For example, the parent of a data
        constructor is its type constructor; the parent of a class op is its
        class.  This relationship corresponds exactly to the Avail data type;
        there may be other places we can exploit it.  (I made the change so that
        version comparison in interface files would be a bit easier; but in
        fact it tided up other things here and there (see calls to
        Name.nameParent).  For example, the declaration pool, of declararations
        read from interface files, but not yet used, is now keyed only by the 'main'
        name of the declaration, not the subordinate names.
      * New types OccEnv and OccSet, with the usual operations.
        OccNames can be efficiently compared, because they have uniques, thanks
        to the hashing implementation of FastStrings.
      * The GlobalRdrEnv is now keyed by OccName rather than RdrName.  Not only
        does this halve the size of the env (because we don't need both qualified
        and unqualified versions in the env), but it's also more efficient because
        we can use a UniqFM instead of a FiniteMap.
        Consequential changes to Provenance, which has moved to RdrName.
      * External Core remains a bit of a hack, as it was before, done with a mixture
        of HsDecls (so that recursiveness and argument variance is still inferred),
        and IfaceExprs (for value declarations).  It's not thoroughly tested.
      	     Minor things
      * DataCon fields dcWorkId, dcWrapId combined into a single field
        dcIds, that is explicit about whether the data con is a newtype or not.
        MkId.mkDataConWorkId and mkDataConWrapId are similarly combined into
      * Choosing the boxing strategy is done for *source* type decls only, and
        hence is now in TcTyDecls, not DataCon.
      * WiredIn names are distinguished by their n_sort field, not by their location,
        which was rather strange
      * Define Maybes.mapCatMaybes :: (a -> Maybe b) -> [a] -> [b]
        and use it here and there
      * Much better pretty-printing of interface files (--show-iface)
      Many, many other small things.
      	     File changes
      * New iface/ subdirectory
      * Much of RnEnv has moved to iface/IfaceEnv
      * MkIface and BinIface have moved from main/ to iface/
      * types/Variance has been absorbed into typecheck/TcTyDecls
      * RnHiFiles and RnIfaces have vanished entirely.  Their
        work is done by iface/LoadIface
      * hsSyn/HsCore has gone, replaced by iface/IfaceSyn
      * typecheck/TcIfaceSig has gone, replaced by iface/TcIface
      * typecheck/TcMonoType has been renamed to typecheck/TcHsType
      * basicTypes/Var.hi-boot and basicTypes/Generics.hi-boot have gone altogether
  33. 06 Feb, 2003 1 commit
    • tgedell's avatar
      [project @ 2003-02-06 19:39:35 by tgedell] · e02e080a
      tgedell authored
      Changed so that PredType is declared as a type and not a datatype,
      this caused a problem when generating external Core.
      Added SourceType as a datatype since PredType refers to it.
  34. 14 Mar, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-03-14 15:47:52 by simonmar] · b9312420
      simonmar authored
      Remove the interface file parser, and move .hi-boot parsing into the
      main parser.  The syntax of .hi-boot files is now greatly improved in
      terms of readability; here's an example:
      	module M where
      	data T
      	f :: T -> GHC.Base.Int
      note that
      	(a) layout can be used
      	(b) there's no explcit export list; everything declared
      	    is implicitly exported
      	(c) Z-encoding of names is no longer required
      	(d) Any identifier not declared in the current module must
      	    still be quailified with the module which originally
      	    defined it (eg. GHC.Base.Int above).
      We'd like to relax (d), but that will come later.
  35. 12 Feb, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-02-12 15:17:13 by simonmar] · 2cc5b907
      simonmar authored
      Switch over to the new hierarchical libraries
      This commit reorganises our libraries to use the new hierarchical
      module namespace extension.
      The basic story is this:
         - fptools/libraries contains the new hierarchical libraries.
           Everything in here is "clean", i.e. most deprecated stuff has
           been removed.
      	- fptools/libraries/base is the new base package
      	  (replacing "std") and contains roughly what was previously
      	  in std, lang, and concurrent, minus deprecated stuff.
      	  Things that are *not allowed* in libraries/base include:
      		Addr, ForeignObj, ByteArray, MutableByteArray,
      		_casm_, _ccall_, ``'', PrimIO
      	  For ByteArrays and MutableByteArrays we use UArray and
      	  STUArray/IOUArray respectively now.
      	  Modules previously called PrelFoo are now under
      	  fptools/libraries/GHC.  eg. PrelBase is now GHC.Base.
      	- fptools/libraries/haskell98 provides the Haskell 98 std.
      	  libraries (Char, IO, Numeric etc.) as a package.  This
      	  package is enabled by default.
      	- fptools/libraries/network is a rearranged version of
      	  the existing net package (the old package net is still
      	  available; see below).
      	- Other packages will migrate to fptools/libraries in
      	  due course.
           NB. you need to checkout fptools/libraries as well as
           fptools/hslibs now.  The nightly build scripts will need to be
         - fptools/hslibs still contains (almost) the same stuff as before.
           Where libraries have moved into the new hierarchy, the hslibs
           version contains a "stub" that just re-exports the new version.
           The idea is that code will gradually migrate from fptools/hslibs
           into fptools/libraries as it gets cleaned up, and in a version or
           two we can remove the old packages altogether.
         - I've taken the opportunity to make some changes to the build
           system, ripping out the old hslibs Makefile stuff from
           mk/target.mk; the new package building Makefile code is in
           mk/package.mk (auto-included from mk/target.mk).
           The main improvement is that packages now register themselves at
           make boot time using ghc-pkg, and the monolithic package.conf
           in ghc/driver is gone.
           I've updated the standard packages but haven't tested win32,
           graphics, xlib, object-io, or OpenGL yet.  The Makefiles in
           these packages may need some further tweaks, and they'll need
           pkg.conf.in files added.
         - Unfortunately all this rearrangement meant I had to bump the
           interface-file version and create a bunch of .hi-boot-6 files :-(
  36. 13 Mar, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-03-13 14:58:25 by simonpj] · 788faebb
      simonpj authored
      	Nuke ClassContext
      This commit tidies up a long-standing inconsistency in GHC.
      The context of a class or instance decl used to be restricted
      to predicates of the form
      	C t1 .. tn
      	type ClassContext = [(Class,[Type])]
      but everywhere else in the compiler we used
      	type ThetaType = [PredType]
      where PredType can be any sort of constraint (= predicate).
      The inconsistency actually led to a crash, when compiling
      	class (?x::Int) => C a where {}
      I've tidied all this up by nuking ClassContext altogether, and using
      PredType throughout.  Lots of modified files, but all in
      more-or-less trivial ways.
      I've also added a check that the context of a class or instance
      decl doesn't include a non-inheritable predicate like (?x::Int).
      Other things
       * rename constructor 'Class' from type TypeRep.Pred to 'ClassP'
         (makes it easier to grep for)
       * rename constructor HsPClass  => HsClassP
      		      HsPIParam => HsIParam
  37. 15 Jul, 1999 1 commit
    • keithw's avatar
      [project @ 1999-07-15 14:08:03 by keithw] · 9d787ef5
      keithw authored
      This commit makes a start at implementing polymorphic usage
      * The module Type has now been split into TypeRep, containing the
        representation Type(..) and other information for `friends' only,
        and Type, providing the public interface to Type.  Due to a bug in
        the interface-file slurping prior to ghc-4.04, {-# SOURCE #-}
        dependencies must unfortunately still refer to TypeRep even though
        they are not friends.
      * Unfoldings in interface files now print as __U instead of __u.
        UpdateInfo now prints as __UA instead of __U.
      * A new sort of variables, UVar, in their own namespace, uvName, has
        been introduced for usage variables.
      * Usage binders __fuall uv have been introduced.  Usage annotations
        are now __u - ty (used once), __u ! ty (used possibly many times),
        __u uv ty (used uv times), where uv is a UVar.  __o and __m have
        gone.  All this still lives only in a TyNote, *for now* (but not for
        much longer).
      * Variance calculation for TyCons has moved from
        typecheck/TcTyClsDecls to types/Variance.
      * Usage annotation and inference are now done together in a single
        pass.  Provision has been made for inferring polymorphic usage
        annotations (with __fuall) but this has not yet been implemented.
        Watch this space!