1. 12 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: disentangle Outputable · accbc242
      Sylvain Henry authored
      - put panic related functions into GHC.Utils.Panic
      - put trace related functions using DynFlags in GHC.Driver.Ppr
      
      One step closer making Outputable fully independent of DynFlags.
      
      Bump haddock submodule
      accbc242
  2. 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:
          haddock.base
          T12227
          T12545
          T12990
          T1969
          T3064
          T5030
          T9872b
      
      Metric Increase:
          haddock.base
          haddock.Cabal
          haddock.compiler
          T12150
          T12234
          T12425
          T12707
          T13035
          T13056
          T15164
          T16190
          T18304
          T1969
          T3064
          T3294
          T5631
          T5642
          T5837
          T6048
          T9020
          T9233
          T9675
          T9872a
          T9961
          WWRec
      6cb84c46
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored
      This is the first step towards implementation of the linear types proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/111).
      
      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
      https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Implementation
      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.
      40fa237e
  3. 21 May, 2020 1 commit
    • Gert-Jan Bottu's avatar
      Explicit Specificity · a9311cd5
      Gert-Jan Bottu authored
      Implementation for Ticket #16393.
      Explicit specificity allows users to manually create inferred type variables,
      by marking them with braces.
      This way, the user determines which variables can be instantiated through
      visible type application.
      
      The additional syntax is included in the parser, allowing users to write
      braces in type variable binders (type signatures, data constructors etc).
      This information is passed along through the renamer and verified in the
      type checker.
      The AST for type variable binders, data constructors, pattern synonyms,
      partial signatures and Template Haskell has been updated to include the
      specificity of type variables.
      
      Minor notes:
      - Bumps haddock submodule
      - Disables pattern match checking in GHC.Iface.Type with GHC 8.8
      a9311cd5
  4. 26 Apr, 2020 1 commit
  5. 07 Apr, 2020 1 commit
  6. 29 Mar, 2020 1 commit
  7. 17 Mar, 2020 1 commit
  8. 08 Feb, 2020 1 commit
  9. 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:
          T4334
      2d4f9ad8
  10. 16 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      Encode shape information in `PmOracle` · 7915afc6
      Sebastian Graf authored
      Previously, we had an elaborate mechanism for selecting the warnings to
      generate in the presence of different `COMPLETE` matching groups that,
      albeit finely-tuned, produced wrong results from an end user's
      perspective in some cases (#13363).
      
      The underlying issue is that at the point where the `ConVar` case has to
      commit to a particular `COMPLETE` group, there's not enough information
      to do so and the status quo was to just enumerate all possible complete
      sets nondeterministically.  The `getResult` function would then pick the
      outcome according to metrics defined in accordance to the user's guide.
      But crucially, it lacked knowledge about the order in which affected
      clauses appear, leading to the surprising behavior in #13363.
      
      In !1010 we taught the term oracle to reason about literal values a
      variable can certainly not take on. This MR extends that idea to
      `ConLike`s and thereby fixes #13363: Instead of committing to a
      particular `COMPLETE` group in the `ConVar` case, we now split off the
      matching constructor incrementally and record the newly covered case as
      a refutable shape in the oracle. Whenever the set of refutable shapes
      covers any `COMPLETE` set, the oracle recognises vacuosity of the
      uncovered set.
      
      This patch goes a step further: Since at this point the information
      in value abstractions is merely a cut down representation of what the
      oracle knows, value abstractions degenerate to a single `Id`, the
      semantics of which is determined by the oracle state `Delta`.
      Value vectors become lists of `[Id]` given meaning to by a single
      `Delta`, value set abstractions (of which the uncovered set is an
      instance) correspond to a union of `Delta`s which instantiate the
      same `[Id]` (akin to models of formula).
      
      Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149
      
      -------------------------
      Metric Decrease:
          ManyAlternatives
          T11195
      -------------------------
      7915afc6
  11. 20 Jun, 2019 1 commit
  12. 15 Mar, 2019 1 commit
  13. 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 pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8
  14. 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.
      
      Acknowledgments:
      This work was completed mostly during Ningning Xie's Google Summer
      of Code, sponsored by Google. It was advised by Richard Eisenberg,
      supported by NSF grant 1704041.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar
      
      Subscribers: RyanGlScott, monoidal, rwbarton, carter
      
      GHC Trac Issues: #15497
      
      Differential Revision: https://phabricator.haskell.org/D5054
      ea5ade34
  15. 23 May, 2018 1 commit
  16. 18 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix scoping of pattern-synonym existentials · f1fe5b4a
      Simon Peyton Jones authored
      This patch fixes Trac #14998, where we eventually decided that
      the existential type variables of the signature of a pattern
      synonym should not scope over the pattern synonym.
      
      See Note [Pattern synonym existentials do not scope] in TcPatSyn.
      f1fe5b4a
  17. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  18. 31 Jul, 2017 1 commit
  19. 28 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix instantiation of pattern synonyms · 6b77914c
      Simon Peyton Jones authored
      In Check.hs (pattern match ovelap checking) we to figure out the
      instantiation of a pattern synonym from the type of the pattern. We
      were doing this utterly wrongly.  Trac #13768 demonstrated this
      bogosity.
      
      The fix is easy; and is described in PatSyn.hs
        Note [Pattern synonym result type]
      6b77914c
  20. 02 Jun, 2017 1 commit
    • Ryan Scott's avatar
      Use lengthIs and friends in more places · a786b136
      Ryan Scott authored
      While investigating #12545, I discovered several places in the code
      that performed length-checks like so:
      
      ```
      length ts == 4
      ```
      
      This is not ideal, since the length of `ts` could be much longer than 4,
      and we'd be doing way more work than necessary! There are already a slew
      of helper functions in `Util` such as `lengthIs` that are designed to do
      this efficiently, so I found every place where they ought to be used and
      did just that. I also defined a couple more utility functions for list
      length that were common patterns (e.g., `ltLength`).
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, goldfire, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: goldfire, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3622
      a786b136
  21. 21 Dec, 2016 1 commit
  22. 05 Aug, 2016 1 commit
  23. 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:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           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
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        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.
      e368f326
    • 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
      77bb0927
  24. 09 Jun, 2016 1 commit
    • niteria's avatar
      Remove Ord PatSyn · b2624ee3
      niteria authored
      It's implemented in terms of Unique which is nondeterministic
      
      GHC Trac: #4012
      b2624ee3
  25. 24 May, 2016 2 commits
  26. 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.
      81aa3d1c
  27. 02 Apr, 2016 1 commit
    • Rik Steenkamp's avatar
      Improve printing of pattern synonym types · 72bd7f7b
      Rik Steenkamp authored
      Add the function `pprPatSynType :: PatSyn -> SDoc` for printing pattern
      synonym types, and remove the ambiguous `patSynType` function. Also,
      the types in a `PatSyn` are now tidy.
      
      Haddock submodule updated to reflect the removal of `patSynType` by
      mpickering.
      
      Fixes: #11213.
      
      Reviewers: goldfire, simonpj, austin, mpickering, bgamari
      
      Reviewed By: simonpj, mpickering
      
      Subscribers: bollmann, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1896
      
      GHC Trac Issues: #11213
      72bd7f7b
  28. 25 Mar, 2016 1 commit
    • Simon Peyton Jones's avatar
      A raft of comments about TyBinders · 067335a6
      Simon Peyton Jones authored
      I had a conversation with Richard about TyBinders
      and VisibilityFlags.  This patch adds a lot of comments
      to explain what is going on.  I feel much more secure now.
      
      Richard please check.
      067335a6
  29. 24 Mar, 2016 1 commit
    • Rik Steenkamp's avatar
      Add `PatSynSigSkol` and modify `PatSynCtxt` · 997312b0
      Rik Steenkamp authored
      As the type of a pattern synonym cannot in general be represented by a
      value of type Type, we cannot use a value `SigSkol (PatSynCtxt n) (Check
      ty)` to represent the signature of a pattern synonym (this causes
      incorrect signatures to be printed in error messages). Therefore we now
      represent it by a value `PatSynSigSkol n` (instead of incorrect
      signatures we simply print no explicit signature).
      
      Furthermore, we rename `PatSynCtxt` to `PatSynBuilderCtxt`, and use
      `SigSkol (PatSynBuilderCtxt n) (Check ty)` to represent the type of a
      bidirectional pattern synonym when used in an expression context.
      Before, this type was represented by a value `SigSkol (PatSynCtxt n)
      (Check ty)`, which caused incorrect error messages.
      
      Also, in `mk_dict_err` of `typecheck\TcErrors.hs` we now distinguish
      between all enclosing implications and "useful" enclosing implications,
      for better error messages concerning pattern synonyms. See `Note [Useful
      implications]`.
      
      See the Phabricator page for examples.
      
      Reviewers: mpickering, goldfire, simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1967
      
      GHC Trac Issues: #11667
      997312b0
  30. 21 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Track specified/invisible more carefully. · 35e93797
      eir@cis.upenn.edu authored
      In particular, this allows correct tracking of specified/invisible
      for variables in Haskell98 data constructors and in pattern synonyms.
      GADT-syntax constructors are harder, and are left until #11721.
      
      This was all inspired by Simon's comments to my fix for #11512,
      which this subsumes.
      
      Test case: ghci/scripts/TypeAppData
      
      [skip ci]  (The test case fails because of an unrelated problem
      fixed in the next commit.)
      35e93797
  31. 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.
      d8c64e86
  32. 16 Feb, 2016 1 commit
  33. 18 Jan, 2016 2 commits
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
    • Simon Peyton Jones's avatar
      Implement scoped type variables in pattern synonyms · e2c7b7ee
      Simon Peyton Jones authored
      This fixes Trac #11351.   The implementation is pretty
      simple, happily.
      
      I took the opportunity to re-order the prov/req context
      in builder-ids, which was confusingly backwards.
      e2c7b7ee
  34. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
  35. 22 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix typechecking for pattern synonym signatures · f40e122b
      Simon Peyton Jones authored
      Various tickets have revealed bad shortcomings in the typechecking of
      pattern type synonyms.  Discussed a lot in (the latter part of)
      Trac #11224.
      
      This patch fixes the most complex issues:
      
      - Both parser and renamer now treat pattern synonyms as an
        ordinary LHsSigType.  Nothing special.  Hooray.
      
      - tcPatSynSig (now in TcPatSyn) typechecks the signature, and
        decomposes it into its pieces.
        See Note [Pattern synonym signatures]
      
      - tcCheckPatSyn has had a lot of refactoring.
        See Note [Checking against a pattern signature]
      
      The result is a lot tidier and more comprehensible.
      Plus, it actually works!
      
      NB: this patch doesn't actually address the precise
          target of #11224, namely "inlining pattern synonym
          does not preserve semantics".  That's an unrelated
          bug, with a separate patch.
      
      ToDo: better documentation in the user manual
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, mpickering, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1685
      
      GHC Trac Issues: #11224
      f40e122b
  36. 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
         features.
      
       * 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.
      67465497