 21 Mar, 2019 1 commit


Ryan Scott authored
When GHC attempts to unify a metavariable with a type containing foralls, it will be rejected as an occurrence of impredicativity. GHC was /not/ extending the same treatment to predicate types, such as in the following (erroneous) example from #11514: ```haskell foo :: forall a. (Show a => a > a) > () foo = undefined ``` This will attempt to instantiate `undefined` at `(Show a => a > a) > ()`, which is impredicative. This patch catches impredicativity arising from predicates in this fashion. Since GHC is pickier about impredicative instantiations, some test cases needed to be updated to be updated so as not to fall afoul of the new validity check. (There were a surprising number of impredicative uses of `undefined`!) Moreover, the `T14828` test case now has slightly less informative types shown with `:print`. This is due to a a much deeper issue with the GHCi debugger (see #14828). Fixes #11514.

 06 Jul, 2018 1 commit


Krzysztof Gogolewski authored
Test Plan: validate Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15342 Differential Revision: https://phabricator.haskell.org/D4933

 14 Jun, 2018 1 commit


Vladislav Zavialov authored
Summary: Implement the "Embrace Type :: Type" GHC proposal, .../ghcproposals/blob/master/proposals/0020notypeintype.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with XDataKinds but not XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in XTypeInType into the XPolyKinds and XDataKinds extensions. * Introduce a new extension XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748

 18 Feb, 2017 1 commit


Ben Gamari authored
This at long last realizes the ideas for typeindexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg > res)) => TypeRep arg > TypeRep res > TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 > k2) (b :: k1). (t ~ a b) => TypeRep a > TypeRep b > TypeRep t   Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon > TypeRep a   Pattern match on a type constructor including its instantiated kind  variables. pattern TRCon' :: forall k (a :: k). TyCon > [SomeTypeRep] > TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) > TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (>) type constructor. Library changes  The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new typeindexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a > SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation  The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous toplevel bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the floatouts don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance  Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arityN sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compiletime overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f5). I've opened #13261 documenting this proposal.

 22 Jun, 2016 1 commit


Gabor Greif authored

 22 Apr, 2016 1 commit


Simon Peyton Jones authored
Provoked by Trac #11948, this patch adds a new warning to GHC Wsimplifiableclassconstraints It warns if you write a class constraint in a type signature that can be simplified by an existing instance declaration. Almost always this means you should simplify it right now; type inference is very fragile without it, as #11948 shows. I've put the warning as onbydefault, but I suppose that if there are howls of protest we can move it out (as happened for Wredundantconstraints. It actually found an example of an overcomplicated context in CmmNode. Quite a few tests use these weird contexts to trigger something else, so I had to suppress the warning in those. The 'haskeline' library has a few occurrences of the warning (which I think should be fixed), so I switched it off for that library in warnings.mk. The warning itself is done in TcValidity.check_class_pred. HOWEVER, when type inference fails we get a type error; and the error suppresses the (informative) warning. So as things stand, the warning only happens when it doesn't cause a problem. Not sure what to do about this, but this patch takes us forward, I think.

 26 Jan, 2016 1 commit


Simon Peyton Jones authored
This code deliberately builds a subtle negativeoccurrenceofdatatype example, described in the paper, so with O it'll give "simplifier ticks exhausted". This patch just adds a comment to explain.

 26 Dec, 2015 1 commit


eir@cis.upenn.edu authored
This may have performance implications.
