1. 08 Feb, 2016 1 commit
  2. 19 Jan, 2016 1 commit
    • niteria's avatar
      Check InScopeSet in substTy and provide substTyUnchecked · 9d33adb6
      niteria authored
      This adds sanity checks to `substTy` that implement:
      > when calling substTy subst ty it should be the case that the in-scope
      > set in the substitution is a superset of
      > * The free vars of the range of the substitution
      > * The free vars of ty minus the domain of the substitution
      and replaces violators with unchecked version. The violators were found
      by running the GHC test suite.
      This ensures that I can work on this incrementally and that what I fix won't
      be undone by some other change.
      It also includes a couple of fixes that I've already done.
      Test Plan: ./validate
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1792
      GHC Trac Issues: #11371
  3. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      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
  4. 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
      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.
  5. 16 Dec, 2015 1 commit
    • quchen's avatar
      Add `-W(no-)xxx` aliases for `-f(no-)warn-xxx` flags · 2206fa8c
      quchen authored
      This also updates the user's guide to refer to the `-W`-based warning
      flags by default.
      Quoting the release note entry:
      | Warnings can now be controlled with `-W(no-)...` flags in addition to
      | the old `-f(no-)warn...` ones. This was done as the first part of a
      | rewrite of the warning system to provide better control over warnings,
      | better warning messages, and more common syntax compared to other
      | compilers. The old `-fwarn...`-based warning flags will remain
      | functional for the forseeable future.
      This is part of
      and addresses #11218
      Reviewed By: hvr, bgamari
      Differential Revision: https://phabricator.haskell.org/D1613
  6. 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.
  7. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
        HsExplicitFlag disappears altogether.
      * Other simplifications
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
           - PatSynSig records a LHsSigType rather than the decomposed
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      * Renamed LHsTyVarBndrs to LHsQTyVars
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      I also did a bunch of loosely-related changes:
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
        All just type synonyms but jolly useful.
      * I record-ised ForeignImport and ForeignExport
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      Updates haddock submodule.
  8. 25 Nov, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor default methods (Trac #11105) · 924f8517
      Simon Peyton Jones authored
      This patch does some signficant refactoring to the treatment
      of default methods in class declarations, and more generally
      to the type checking of type/class decls.
      * When the class has a generic-default method, such as
           class C a where
             op :: a -> a -> Bool
             default op :: Ord a => a -> a -> a
        the ClassOpItem records the type of the generic-default,
        in this case the type (Ord a => a -> a -> a)
      * I killed off Class.DefMeth in favour of the very-similar
        BasicTypes.DefMethSpec.  However it turned out to be better
        to use a Maybe, thus
            Maybe (DefMethSpec Type)
        with Nothing meaning "no default method".
      * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing],
        but I found a way to make it much simpler, accumulating only
        a [TyCon].  Much less wrapping and unwrapping.
      * On the way I also fixed Trac #10896 in a better way. Instead
        of killing off all ambiguity checks whenever there are any type
        errors (the fix in commit 8e8b9ed9), I instead recover in
      There was a lot of associated simplification all round
  9. 01 Nov, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations: BooleanFormula is not properly Located · f16827f8
      Alan Zimmerman authored
      At the moment BooleanFormula is defined as
        data BooleanFormula a = Var a | And [BooleanFormula a]
                              | Or [BooleanFormula a]
             deriving (Eq, Data, Typeable, Functor, Foldable, Traversable)
      An API Annotation can only be attached to an item of the form Located a.
      Replace this with a properly Located version, and attach the appropriate
      API Annotations to it
      Updates haddock submodule.
      Test Plan: ./validate
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D1384
      GHC Trac Issues: #11017
  10. 03 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Fill in associated type defaults with DeriveAnyClass · 2f74be9c
      Ryan Scott authored
      Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in
      associated type family defaults when deriving a class which contained
      In order to fix this properly, `tcATDefault` needed to be used from
      `TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved
      from `TcInstDcls` to `TcClsDcl`.
      Fixes #10361.
      Test Plan: ./validate
      Reviewers: kosmikus, dreixel, bgamari, austin, simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1283
      GHC Trac Issues: #10361
  11. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Tidy up and refactor wildcard handling · 95364812
      Simon Peyton Jones authored
      When examining #10615, I found the wildcard handling hard
      to understand.  This patch refactors quite a bit, but with
      no real change in behaviour.
       * Split out TcIdSigInfo from TcSigInfo, as a separate type,
         like TcPatSynInfo.
       * Make TcIdSigInfo express more invariants by pushing the
         wildard info into TcIdSigBndr
       * Remove all special treatment of unification variables that arise
         from wildcards; so the TauTv of TcType.MetaInfo loses its Bool
      A ton of konck on changes.  The result is significantly simpler, I think.
  12. 21 Jul, 2015 1 commit
    • Simon Peyton Jones's avatar
      Add NOINLINE for hs-boot functions · efa7b3a4
      Simon Peyton Jones authored
      This fixes Trac #10083.
      The key change is in TcBinds.tcValBinds, where we construct
      the prag_fn.  With this patch we add a NOINLINE pragma for
      any functions that were exported by the hs-boot file for this
      See Note [Inlining and hs-boot files], and #10083, for details.
      The commit touches several other files becuase I also changed the
      representation of the "pragma function" from a function TcPragFun
      to an environment, TcPragEnv. This makes it easer to extend
      during construction.
  13. 24 Mar, 2015 1 commit
    • Simon Peyton Jones's avatar
      Improve environment handling in TcBinds · 8eaa70a6
      Simon Peyton Jones authored
      This is a minor refactoring, but it simplifies the code quite a bit
      * Decrease the number of variants of tcExtend in TcEnv
      * Remove "not_actually_free" from TcEnv.tc_extend_local_env2
      * Simplify plumbingof the "closed" flag
      * Remove redundant scoping of wild-card variables
  14. 19 Feb, 2015 1 commit
    • thomasw's avatar
      Fix #10045 · e9d72cef
      thomasw authored
      SPJ's solution is to only bring the `TcId` (which includes the type) of a
      binder into scope when it had a non-partial type signature.
      Take care of this by only storing the `TcId` in `TcSigInfo` of non-partial
      type signatures, hence the change to `sig_poly_id :: Maybe TcId`. Only in case
      of a `Just` will we bring the `TcId` in scope. We still need to know the name
      of the binder, even when it has a partial type signature, so add a `sig_name
      :: Name` field. The field `sig_partial :: Bool` is no longer necessary, so
      reimplement `isPartialSig` in terms of `sig_poly_id`.
      Note that the new test case fails, but not because of a panic, but because the
      `Num a` constraint is missing. Adding an extra-constraints wildcard to
      `copy`'s signature would fix it.
      Test Plan: validate
      Reviewers: simonpj, austin
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D646
      GHC Trac Issues: #10045
  15. 16 Jan, 2015 1 commit
    • Alan Zimmerman's avatar
      API Annotations tweaks. · 11881ec6
      Alan Zimmerman authored
      HsTyLit now has SourceText
      Update documentation of HsSyn to reflect which annotations are attached to which element.
      Ensure that the parser always keeps HsSCC and HsTickPragma values, to
      be ignored in the desugar phase if not needed
      Bringing in SourceText for pragmas
      Add Location in NPlusKPat
      Add Location in FunDep
      Make RecCon payload Located
      Explicitly add AnnVal to RdrName where it is compound
      Add Location in IPBind
      Add Location to name in IEThingAbs
      Add Maybe (Located id,Bool) to Match to track fun_id,infix
        This includes converting Match into a record and adding a note about why
        the fun_id needs to be replicated in the Match.
      Add Location in KindedTyVar
      Sort out semi-colons for parsing
        - import statements
        - stmts
        - decls
        - decls_cls
        - decls_inst
      This updates the haddock submodule.
      Test Plan: ./validate
      Reviewers: hvr, austin, goldfire, simonpj
      Reviewed By: simonpj
      Subscribers: thomie, carter
      Differential Revision: https://phabricator.haskell.org/D538
  16. 06 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Major patch to add -fwarn-redundant-constraints · 32973bf3
      Simon Peyton Jones authored
      The idea was promted by Trac #9939, but it was Christmas, so I did
      some recreational programming that went much further.
      The idea is to warn when a constraint in a user-supplied context is
      redundant.  Everything is described in detail in
        Note [Tracking redundant constraints]
      in TcSimplify.
      Main changes:
       * The new ic_status field in an implication, of type ImplicStatus.
         It replaces ic_insol, and includes information about redundant
       * New function TcSimplify.setImplicationStatus sets the ic_status.
       * TcSigInfo has sig_report_redundant field to say whenther a
         redundant constraint should be reported; and similarly
         the FunSigCtxt constructor of UserTypeCtxt
       * EvBinds has a field eb_is_given, to record whether it is a given
         or wanted binding. Some consequential chagnes to creating an evidence
         binding (so that we record whether it is given or wanted).
       * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds;
         see Note [Typechecking plan for instance declarations] in
       * Some significant changes to the type checking of instance
         declarations; Note [Typechecking plan for instance declarations]
         in TcInstDcls.
       * I found that TcErrors.relevantBindings was failing to zonk the
         origin of the constraint it was looking at, and hence failing to
         find some relevant bindings.  Easy to fix, and orthogonal to
         everything else, but hard to disentangle.
      Some minor refactorig:
       * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds
       * TcClassDcl and TcInstDcls now have their own code for typechecking
         a method body, rather than sharing a single function. The shared
         function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code
         and the differences were growing confusing.
       * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and
         use it
       * Add new function Bag.catBagMaybes, and use it in TcSimplify
  17. 03 Dec, 2014 1 commit
  18. 01 Dec, 2014 1 commit
  19. 28 Nov, 2014 1 commit
  20. 20 Nov, 2014 1 commit
    • cactus's avatar
      Add support for pattern synonym type signatures. · cce6318e
      cactus authored
      Syntax is of the form
          pattern P :: (Prov b) => (Req a) => a -> b -> Int -> T a
      which declares a pattern synonym called `P`, with argument types `a`, `b`,
      and `Int`, and result type `T a`, with provided context `(Prov b)` and required
      context `(Req a)`.
      The Haddock submodule is also updated to use this new syntax in generated docs.
  21. 26 Sep, 2014 1 commit
  22. 15 May, 2014 1 commit
    • 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.
  23. 13 Apr, 2014 1 commit
  24. 13 Feb, 2014 1 commit
  25. 20 Jan, 2014 1 commit
    • cactus's avatar
      Implement pattern synonyms · 4f8369bf
      cactus authored
      This patch implements Pattern Synonyms (enabled by -XPatternSynonyms),
      allowing y ou to assign names to a pattern and abstract over it.
      The rundown is this:
        * Named patterns are introduced by the new 'pattern' keyword, and can
          be either *unidirectional* or *bidirectional*. A unidirectional
          pattern is, in the simplest sense, simply an 'alias' for a pattern,
          where the LHS may mention variables to occur in the RHS. A
          bidirectional pattern synonym occurs when a pattern may also be used
          in expression context.
        * Unidirectional patterns are declared like thus:
              pattern P x <- x:_
          The synonym 'P' may only occur in a pattern context:
              foo :: [Int] -> Maybe Int
              foo (P x) = Just x
              foo _     = Nothing
        * Bidirectional patterns are declared like thus:
              pattern P x y = [x, y]
          Here, P may not only occur as a pattern, but also as an expression
          when given values for 'x' and 'y', i.e.
              bar :: Int -> [Int]
              bar x = P x 10
        * Patterns can't yet have their own type signatures; signatures are inferred.
        * Pattern synonyms may not be recursive, c.f. type synonyms.
        * Pattern synonyms are also exported/imported using the 'pattern'
          keyword in an import/export decl, i.e.
              module Foo (pattern Bar) where ...
          Note that pattern synonyms share the namespace of constructors, so
          this disambiguation is required as a there may also be a 'Bar'
          type in scope as well as the 'Bar' pattern.
        * The semantics of a pattern synonym differ slightly from a typical
          pattern: when using a synonym, the pattern itself is matched,
          followed by all the arguments. This means that the strictness
          differs slightly:
              pattern P x y <- [x, y]
              f (P True True) = True
              f _             = False
              g [True, True] = True
              g _            = False
          In the example, while `g (False:undefined)` evaluates to False,
          `f (False:undefined)` results in undefined as both `x` and `y`
          arguments are matched to `True`.
      For more information, see the wiki:
          https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/ImplementationReviewed-by: Simon Peyton Jones's avatarSimon Peyton Jones <simonpj@microsoft.com>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
  26. 01 Oct, 2013 2 commits
  27. 18 Sep, 2013 1 commit
  28. 10 Sep, 2013 1 commit
    • Simon Peyton Jones's avatar
      Improve error reporting for "relevant bindings" again (Trac #8233) · 9039108b
      Simon Peyton Jones authored
      This patch makes a number of related improvements:
      * Displays relevant bindings in innermost-first order.
        The inner ones are closer to the error.
      * Does not display syntactically top-level bindings,
        unless you say -fno-max-relevant-bindings.
        This is what Trac #8233 was mainly about
      * Makes the TopLevelFlag in a TcIdBinder really mean
        "syntactically top level".  It was a bit vague before.
      There was some associated simplification, because we no longer
      need to pas a TopLevelFlag to tcMonoBinds and friends.
  29. 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
  30. 17 Sep, 2012 1 commit
  31. 07 Jun, 2012 1 commit
    • Simon Peyton Jones's avatar
      Support polymorphic kind recursion · c9117200
      Simon Peyton Jones authored
      This is (I hope) the last major patch for kind polymorphism.
      The big new feature is polymorphic kind recursion when you
      supply a complete kind signature for a type constructor.
      (I've documented it in the user manual too.)
      This fixes Trac #6137, #6093, #6049.
      The patch also makes type/data families less polymorphic by default.
         data family T a
      now defaults to T :: * -> *
      If you want T :: forall k. k -> *, use
         data family T (a :: k)
      This defaulting to * is done whenever there is a
      "complete, user-specified kind signature", something that is
      carefully defined in the user manual.
  32. 05 Jun, 2012 1 commit
  33. 22 Mar, 2012 1 commit
  34. 02 Mar, 2012 1 commit
    • Simon Peyton Jones's avatar
      Hurrah! This major commit adds support for scoped kind variables, · 3bf54e78
      Simon Peyton Jones authored
      which (finally) fills out the functionality of polymorphic kinds.
      It also fixes numerous bugs.
      Main changes are:
      Renaming stuff
      * New type in HsTypes:
           data HsBndrSig sig = HsBSig sig [Name]
        which is used for type signatures in patterns, and kind signatures
        in types.  So when you say
             f (x :: [a]) = x ++ x
             data T (f :: k -> *) (x :: *) = MkT (f x)
        the signatures in both cases are a HsBndrSig.
      * The [Name] in HsBndrSig records the variables bound by the
        pattern, that is 'a' in the first example, 'k' in the second,
        and nothing in the third.  The renamer initialises the field.
      * As a result I was able to get rid of
           RnHsSyn.extractHsTyNames :: LHsType Name -> NameSet
        and its friends altogether.  Deleted the entire module!
        This led to some knock-on refactoring; in particular the
        type renamer now returns the free variables just like the
        term renamer.
      Kind-checking types: mainly TcHsType
      A major change is that instead of kind-checking types in two
      passes, we now do one. Under the old scheme, the first pass did
      kind-checking and (hackily) annotated the HsType with the
      inferred kinds; and the second pass desugared the HsType to a
      Type.  But now that we have kind variables inside types, the
      first pass (TcHsType.tc_hs_type) can go straight to Type, and
      zonking will squeeze out any kind unification variables later.
      This is much nicer, but it was much more fiddly than I had expected.
      The nastiest corner is this: it's very important that tc_hs_type
      uses lazy constructors to build the returned type. See
      Note [Zonking inside the knot] in TcHsType.
      Type-checking type and class declarations: mainly TcTyClsDecls
      I did tons of refactoring in TcTyClsDecls.  Simpler and nicer now.
      Typechecking bindings: mainly TcBinds
      I rejigged (yet again) the handling of type signatures in TcBinds.
      It's a bit simpler now.  The main change is that tcTySigs goes
      right through to a TcSigInfo in one step; previously it was split
      into two, part here and part later.
      Unsafe coercions
      Usually equality coercions have exactly the same kind on both
      sides.  But we do allow an *unsafe* coercion between Int# and Bool,
      say, used in
          case error Bool "flah" of { True -> 3#; False -> 0# }
          (error Bool "flah") |> unsafeCoerce Bool Int#
      So what is the instantiation of (~#) here?
         unsafeCoerce Bool Int# :: (~#) ??? Bool Int#
      I'm using OpenKind here for now, but it's un-satisfying that
      the lhs and rhs of the ~ don't have precisely the same kind.
      More minor
      * HsDecl.TySynonym has its free variables attached, which makes
        the cycle computation in TcTyDecls.mkSynEdges easier.
      * Fixed a nasty reversed-comparison bug in FamInstEnv:
        @@ -490,7 +490,7 @@ lookup_fam_inst_env' match_fun one_sided ie fam tys
           n_tys = length tys
           extra_tys = drop arity tys
           (match_tys, add_extra_tys)
      -       | arity > n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
      +       | arity < n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
              | otherwise     = (tys,            \res_tys -> res_tys)
  35. 19 Jan, 2012 1 commit
  36. 05 Dec, 2011 1 commit
    • Simon Peyton Jones's avatar
      Allow full constraint solving under a for-all (Trac #5595) · 2e6dcdf7
      Simon Peyton Jones authored
      The main idea is that when we unify
          forall a. t1  ~  forall a. t2
      we get constraints from unifying t1~t2 that mention a.
      We are producing a coercion witnessing the equivalence of
      the for-alls, and inside *that* coercion we need bindings
      for the solved constraints arising from t1~t2.
      We didn't have way to do this before.  The big change is
      that here's a new type TcEvidence.TcCoercion, which is
      much like Coercion.Coercion except that there's a slot
      for TcEvBinds in it.
      This has a wave of follow-on changes. Not deep but broad.
      * New module TcEvidence, which now contains the HsWrapper
        TcEvBinds, EvTerm etc types that used to be in HsBinds
      * The typechecker works exclusively in terms of TcCoercion.
      * The desugarer converts TcCoercion to Coercion
      * The main payload is in TcUnify.unifySigmaTy. This is the
        function that had a gross hack before, but is now beautiful.
      * LCoercion is gone!  Hooray.
      Many many fiddly changes in conssequence.  But it's nice.
  37. 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
  38. 04 Nov, 2011 1 commit
  39. 09 Sep, 2011 1 commit
    • batterseapower's avatar
      Implement associated type defaults · de8c8d68
      batterseapower authored
      Basically, now you can write:
        class Cls a where
          type Typ a
          type Typ a = Just a
      And now if an instance does not specify an explicit associated type
      instance, one will be generated afresh based on that default. So for
      example this instance:
        instance Cls Int where
      Will be equivalent to this one:
        instance Cls Int where
          type Typ Int = Just Int