summaryrefslogtreecommitdiff
path: root/compiler/main/PprTyThing.hs
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Core (#13009)Sylvain Henry2020-02-261-205/+0
| | | | Update haddock submodule
* Modules: Driver (#13009)Sylvain Henry2020-02-211-1/+1
| | | | submodule updates: nofib, haddock
* Module hierarchy: Iface (cf #13009)Sylvain Henry2020-01-061-14/+14
|
* Fix typos, via a Levenshtein-style correctorBrian Wignall2020-01-041-1/+1
|
* Ensure that coreView/tcView are able to inlineBen Gamari2019-11-131-3/+2
| | | | | | | | | | | | | | | | | | | | 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
* Print explicit foralls in type family eqns when appropriateRyan Scott2018-11-261-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When `-fprint-explicit-foralls` is enabled, type family equations are either printed without an explict `forall` entirely, or with a bizarre square bracket syntax (in the case of closed type families). I find neither satisfying, so in this patch, I introduce support for printing explicit `forall`s in open type-family, closed type-family, and data-family equations when appropriate. (By "when appropriate", I refer to the conditions laid out in `Note [When to print foralls]` in `IfaceType`.) One tricky point in the implementation is that I had to pick a visibility for each type variable in a `CoAxiom`/`FamInst` in order to be able to pass it to `pprUserIfaceForAll` //et al.// Because the type variables in a type family instance equation can't be instantiated by the programmer anyway, the choice only really matters for pretty-printing purposes, so I simply went with good ol' trustworthy `Specified`. (This design choice is documented in `Note [Printing foralls in type family instances]` in `IfaceType`.) Test Plan: make test TEST=T15827 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15827 Differential Revision: https://phabricator.haskell.org/D5282
* Add comments about pretty-printing via IfaceSynSimon Peyton Jones2018-08-241-29/+58
| | | | | Provoked by discussion on Phab:D5097 (Trac #15546), I'm adding a big Note explaing the strategy of pretty-printing via IfaceSyn
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | 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
* Show explicit quantifiers in conflicting definitions errorPhil de Joux2017-01-201-31/+38
| | | | | | | | | | | | | | | | This fixes #12441, where definitions in a Haskell module and its boot file which differed only in their quantifiers produced a confusing error message. Here we teach GHC to always show quantifiers for these errors. Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari Reviewed By: bgamari Subscribers: snowleopard, simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2734 GHC Trac Issues: #12441
* Refine imports slightlySimon Peyton Jones2016-06-101-1/+1
|
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-181-3/+2
| | | | | | | | | | | | | | | | | | | | 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
* Visible type applicationRichard Eisenberg2015-12-241-10/+2
| | | | | | | | | | | | | 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.
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* catch some recent typosGabor Greif2014-12-081-1/+1
|
* White space onlySimon Peyton Jones2014-11-041-1/+1
|
* main: detabify/unwhitespace PprTyThingAustin Seipp2014-07-201-15/+8
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Some typos in commentsGabor Greif2014-06-111-1/+1
|
* Comments only (related to Trac #7730)Simon Peyton Jones2014-06-031-4/+40
|
* Do pretty-printing of TyThings via IfaceDecl (Trac #7730)Simon Peyton Jones2014-06-031-249/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the initial work on this was done fy 'archblob' (fcsernik@gmail.com); thank you! I reviewed the patch, started some tidying, up and then ended up in a huge swamp of changes, not all of which I can remember now. But: * To suppress kind arguments when we have -fno-print-explicit-kinds, - IfaceTyConApp argument types are in a tagged list IfaceTcArgs * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType. * When printing data/type family instances for the user, I've made them print out an informative RHS, which is a new feature. Thus ghci> info T data family T a data instance T Int = T1 Int Int data instance T Bool = T2 * In implementation terms, pprIfaceDecl has just one "context" argument, of type IfaceSyn.ShowSub, which says - How to print the binders of the decl see note [Printing IfaceDecl binders] in IfaceSyn - Which sub-comoponents (eg constructors) to print * Moved FastStringEnv from RnEnv to OccName It all took a ridiculously long time to do. But it's done!
* Refactoring around TyCon.isSynTyConSimon Peyton Jones2014-05-151-1/+1
| | | | | | | | | | * Document isSynTyCon better * Add isTypeSyonymTyCon for regular H98 type synonyms * Use isTypeSynonymTyCon rather than isSynTyCon where the former is really intended All arose as part of a bug I introduced when fixing Trac #9102, thinking that isSynTyCon meant H98 type syononyms.
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-1/+1
| | | | | | | | | | | | | | | | | | 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.
* Modularise pretty-printing for forallsSimon Peyton Jones2014-05-061-6/+2
| | | | | | | | | See TypeRep.pprUserForAll. This just makes forall-printing a bit more consistent. In particular, I wasn't seeing the kind foralls when displaying a CoAxiom or CoAxBranch The output on T7939 is just possible a bit too verbose now, but even if so that's an error in the right direction.
* Print for-alls more often (Trac #9018)Simon Peyton Jones2014-04-281-7/+4
| | | | | | | | We now display the foralls of a type if any of the type variables is polykinded. This put kind polymorphism "in your face" a bit more often, but eliminates a lot of head scratching. The user manual reflects the new behaviour.
* Reinstate pretty-printing of AnIds via pprId (#8776)Dr. ERDI Gergo2014-03-141-0/+6
|
* Pretty-print the following TyThings via their IfaceDecl counterpart:Dr. ERDI Gergo2014-03-131-46/+13
| | | | | | * AnId * ACoAxiom * AConLike
* Implement pattern synonymsDr. ERDI Gergo2014-01-201-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation Reviewed-by: Simon Peyton Jones <simonpj@microsoft.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Don't print roles for data instancesSimon Peyton Jones2014-01-171-1/+3
| | | | See Trac #8672
* Be more selective about when to print out roles with :infoRichard Eisenberg2013-10-231-8/+12
|
* Print (non-representational) roles when display TyCon informationSimon Peyton Jones2013-10-081-14/+25
|
* Simplify PprTyThingSimon Peyton Jones2013-10-041-53/+53
| | | | | | | In particular, don't import GHC (a historical hangover), which makes this module live much lower down in the module hierarchy. This in turn means we can call it from TcRnDriver
* Improve pretty-printing of typesunknown2013-10-011-75/+81
| | | | | | | | | | | | | | | * The main change is to suppress printing (in types) of kind for-alls kind applications The new flag -fprint-explicit-kinds prints them as before (by analogy with the existing -fprint-explicit-foralls) * I also took advantage of the fact that SDoc now has access to DynFlags, to tidy up the way in which explicit for-alls are printed. Instead of passing a boolean flag around, we now simply consult the DynFlags. Much neater. I still need to add documentation for the flag
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-1/+1
|
* Add support for evaluation of type-level natural numbers.Iavor S. Diatchki2013-09-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This patch implements some simple evaluation of type-level expressions featuring natural numbers. We can evaluate *concrete* expressions that use the built-in type families (+), (*), (^), and (<=?), declared in GHC.TypeLits. We can also do some type inference involving these functions. For example, if we encounter a constraint such as `(2 + x) ~ 5` we can infer that `x` must be 3. Note, however, this is used only to resolve unification variables (i.e., as a form of a constraint improvement) and not to generate new facts. This is similar to how functional dependencies work in GHC. The patch adds a new form of coercion, `AxiomRuleCo`, which makes use of a new form of axiom called `CoAxiomRule`. This is the form of evidence generate when we solve a constraint, such as `(1 + 2) ~ 3`. The patch also adds support for built-in type-families, by adding a new form of TyCon rhs: `BuiltInSynFamTyCon`. such built-in type-family constructors contain a record with functions that are used by the constraint solver to simplify and improve constraints involving the built-in function (see `TcInteract`). The record in defined in `FamInst`. The type constructors and rules for evaluating the type-level functions are in a new module called `TcTypeNats`.
* Added support for writing and checking closed type families is hs-boot files.Richard Eisenberg2013-08-051-2/+7
| | | | | | | | As documented in the users' guide, you can now write type family Foo a where .. in a hs-boot file to declare an abstract closed type family.
* Revise implementation of overlapping type family instances.Richard Eisenberg2013-06-211-4/+9
| | | | | | | | | | | | | | | | | | | This commit changes the syntax and story around overlapping type family instances. Before, we had "unbranched" instances and "branched" instances. Now, we have closed type families and open ones. The behavior of open families is completely unchanged. In particular, coincident overlap of open type family instances still works, despite emails to the contrary. A closed type family is declared like this: > type family F a where > F Int = Bool > F a = Char The equations are tried in order, from top to bottom, subject to certain constraints, as described in the user manual. It is not allowed to declare an instance of a closed family.
* Print kinds of non-* tyvar binders in pprTyThingSimon Peyton Jones2013-05-281-5/+6
| | | | This makes the output of :info more useful
* Don't suppress foralls in the RHS of a type synonym definition!Simon Peyton Jones2013-05-031-2/+2
| | | | Fixes Trac #7872
* Display operators using parentheses/backticks in error messages (#7848)Krzysztof Gogolewski2013-04-211-1/+1
|
* Pure refactoringSimon Peyton Jones2013-01-281-0/+1
| | | | | | | | | | | | | * Move tidyType and friends from TcType to TypeRep (It was always wrong to have it in TcType.) * Move mkCoAxBranch and friends from FamInst to Coercion * Move pprCoAxBranch and friends from FamInstEnv to Coercion No change in functionality, though there might be a little wibble in error message output, because I combined two different functions both called pprCoAxBranch!
* When printing types in the interactive UI, take account of free variablesSimon Peyton Jones2013-01-221-1/+6
| | | | | | | Often the types we print are full-generalised, but in fact *kinds* are not, so we need to use tidyOpenType. Fixes Trac #7587
* Be willing to parse {-# UNPACK #-} without '!'Simon Peyton Jones2013-01-141-2/+2
| | | | | | | | | | | | This change gives a more helpful error message when the user says data T = MkT {-# UNPACK #-} Int which should have a strictness '!' as well. Rather than just a parse error, we get T7562.hs:3:14: Warning: UNPACK pragma lacks '!' on the first argument of `MkT' Fixes Trac #7562
* Make {-# UNPACK #-} work for type/data family invocationsSimon Peyton Jones2012-12-231-2/+1
| | | | | | | | | | | | | | | | | | | | | This fixes most of Trac #3990. Consider data family D a data instance D Double = CD Int Int data T = T {-# UNPACK #-} !(D Double) Then we want the (D Double unpacked). To do this we need to construct a suitable coercion, and it's much safer to record that coercion in the interface file, lest the in-scope instances differ somehow. That in turn means elaborating the HsBang type to include a coercion. To do that I moved HsBang from BasicTypes to DataCon, which caused quite a few minor knock-on changes. Interface-file format has changed! Still to do: need to do knot-tying to allow instances to take effect within the same module.
* Wibbles to faa8ff40 (UNPACK pragmas)Simon Peyton Jones2012-12-191-4/+20
| | | | Nothing big here, just tidying up deetails
* Make a start towards eta-rules and injective familiesSimon Peyton Jones2012-09-181-7/+7
| | | | | | | | | | | | | | | | | | | | * Make Any into a type family (which it should always have been) This is to support the future introduction of eta rules for product types (see email on ghc-users title "PolyKind issue" early Sept 2012) * Add the *internal* data type support for (a) closed type families [so that you can't give type instance for 'Any'] (b) injective type families [because Any is really injective] This amounts to two boolean flags on the SynFamilyTyCon constructor of TyCon.SynTyConRhs. There is some knock-on effect, but all of a routine nature. It remains to offer source syntax for either closed or injective families.
* Use -fwarn-tabs when validatingIan Lynagh2011-11-041-0/+7
| | | | | We only use it for "compiler" sources, i.e. not for libraries. Many modules have a -fno-warn-tabs kludge for now.
* Implement -XConstraintKindMax Bolingbroke2011-09-061-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Some minor wibbling in printing source locationsSimon Peyton Jones2011-09-021-3/+2
| | | | | | | | | | | I found that an imported instance was getting printed with <no location info>. Fixing this pushed me into a bit more refactoring than I intended, but it's all small aesthetic stuff, nothing fundamental. Caused some error message to change as a result. I removed pprDefnLoc from the GHC API because it doesn't seem to be used. Name.pprNamedefnLoc and pprDefinedAt are probably more useful anyway.
* Minor wibbles to pretty-printing HsSynSimon Peyton Jones2011-08-231-11/+13
| | | | | Mainly affecting how declarations are printed Ie by default: laid out with no braces
* Make pprTyThingInContenxt handle associated types rightSimon Peyton Jones2011-08-221-54/+59
| | | | | | Just as we want to display a data constructor as part of its parent data type declaration, so with associated types. This was simply missing before.
* The final batch of changes for the new coercion representationSimon Peyton Jones2011-05-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | * Fix bugs in the packing and unpacking of data constructors with equality predicates in their types * Remove PredCo altogether; instead, coercions between predicated types (like (Eq a, [a]~b) => blah) are treated as if they were precisely their underlying representation type Eq a -> ((~) [a] b) -> blah in this case * Similarly, Type.coreView no longer treats equality predciates specially. * Implement the cast-of-coercion optimisation in Simplify.simplCoercionF Numerous other small bug-fixes and refactorings. Annoyingly, OptCoercion had Windows line endings, and this patch switches to Unix, so it looks as if every line has changed.
View Lorry Controller Status