1. 29 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #14045 by omitting an unnecessary check · d1ef223c
      Richard Eisenberg authored
      Previously, we checked the number of patterns in a data instances
      for all data families whose kind did not end in a kind variable.
      But, of course, undersaturating instances can happen even without
      the kind ending in a kind variable. So I've omitted the arity check.
      Data families aren't as particular about their arity as type families
      are (because data families can be undersaturated). Still, this change
      degrades error messages when instances don't have the right arity;
      now, instead of reporting a simple mismatch in the number of patterns,
      GHC reports kind errors. The new errors are fully accurate, but perhaps
      not as easy to work with. Still, with the new flexibility of allowing
      data family instances with varying numbers of patterns, I don't see
      a better way.
      
      This commit also improves source fidelity in some error messages,
      requiring more changes than really are necessary. But without these
      changes, error messages around mismatched associated instance heads
      were poor.
      
      test cases: indexed-types/should_compile/T14045,
                  indexed-types/should_fail/T14045a
      d1ef223c
  2. 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
  3. 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
  4. 15 Jul, 2014 1 commit
    • Simon Peyton Jones's avatar
      Entirely re-jig the handling of default type-family instances (fixes Trac #9063) · 9b8ba629
      Simon Peyton Jones authored
      In looking at Trac #9063 I decided to re-design the default
      instances for associated type synonyms.  Previously it was all
      jolly complicated, to support generality that no one wanted, and
      was arguably undesirable.
      
      Specifically
      
      * The default instance for an associated type can have only
        type variables on the LHS.  (Not type patterns.)
      
      * There can be at most one default instances declaration for
        each associated type.
      
      To achieve this I had to do a surprisingly large amount of refactoring
      of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
      of the LHS patterns.
      
      That change in HsDecls has a (trivial) knock-on effect in Haddock, so
      this commit does a submodule update too.
      
      The net result is good though.  The code is simpler; the language
      specification is simpler.  Happy days.
      
      Trac #9263 and #9264 are thereby fixed as well.
      9b8ba629
  5. 25 Feb, 2014 1 commit
  6. 21 Jun, 2013 1 commit
  7. 24 Feb, 2013 1 commit
  8. 26 Mar, 2012 1 commit
  9. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 5e1333af
      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
      5e1333af
  10. 20 Jul, 2011 1 commit
  11. 01 Jan, 2010 1 commit
  12. 28 Nov, 2009 1 commit
  13. 20 Aug, 2007 1 commit
  14. 05 Jan, 2007 1 commit
  15. 23 Oct, 2006 1 commit