summaryrefslogtreecommitdiff
path: root/libraries/template-haskell/Language/Haskell/TH/Lib.hs
Commit message (Collapse)AuthorAgeFilesLines
* Allow generation of TTH syntax with THOleg Grenrus2023-04-121-1/+1
| | | | | | | | | | | | | | | | | | | | In other words allow generation of typed splices and brackets with Untyped Template Haskell. That is useful in cases where a library is build with TTH in mind, but we still want to generate some auxiliary declarations, where TTH cannot help us, but untyped TH can. Such example is e.g. `staged-sop` which works with TTH, but we would like to derive `Generic` declarations with TH. An alternative approach is to use `unsafeCodeCoerce`, but then the derived `Generic` instances would be type-checked only at use sites, i.e. much later. Also `-ddump-splices` output is quite ugly: user-written instances would use TTH brackets, not `unsafeCodeCoerce`. This commit doesn't allow generating of untyped template splices and brackets with untyped TH, as I don't know why one would want to do that (instead of merging the splices, e.g.)
* Handle type data declarations in Template Haskell quotations and splices ↵Ross Paterson2022-12-031-3/+11
| | | | | | | (fixes #22500) This adds a TypeDataD constructor to the Template Haskell Dec type, and ensures that the constructors it contains go in the TyCls namespace.
* Export liftA2 from PreludeGeorgi Lyubenov2022-09-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changes: In order to be warning free and compatible, we hide Applicative(..) from Prelude in a few places and instead import it directly from Control.Applicative. Please see the migration guide at https://github.com/haskell/core-libraries-committee/blob/main/guides/export-lifta2-prelude.md for more details. This means that Applicative is now exported in its entirety from Prelude. Motivation: This change is motivated by a few things: * liftA2 is an often used function, even more so than (<*>) for some people. * When implementing Applicative, the compiler will prompt you for either an implementation of (<*>) or of liftA2, but trying to use the latter ends with an error, without further imports. This could be confusing for newbies. * For teaching, it is often times easier to introduce liftA2 first, as it is a natural generalisation of fmap. * This change seems to have been unanimously and enthusiastically accepted by the CLC members, possibly indicating a lot of love for it. * This change causes very limited breakage, see the linked issue below for an investigation on this. See https://github.com/haskell/core-libraries-committee/issues/50 for the surrounding discussion and more details.
* Implement \cases (Proposal 302)Jakob Bruenker2022-04-011-3/+3
| | | | | | | | | | | | This commit implements proposal 302: \cases - Multi-way lambda expressions. This adds a new expression heralded by \cases, which works exactly like \case, but can match multiple apats instead of a single pat. Updates submodule haddock to support the ITlcases token. Closes #20768
* Add PromotedInfixT/PromotedUInfixT to THJakob Brünker2021-12-111-3/+3
| | | | | | | | | | | | Previously, it was not possible to refer to a data constructor using InfixT with a dynamically bound name (i.e. a name with NameFlavour `NameS` or `NameQ`) if a type constructor of the same name exists. This commit adds promoted counterparts to InfixT and UInfixT, analogously to how PromotedT is the promoted counterpart to ConT. Closes #20773
* Handle OverloadedRecordDot in TH (#20185)Zubin Duggal2021-08-031-0/+1
|
* template-haskell: Add support for default declarationsMario Blažević2021-07-211-0/+3
| | | | Fixes #19373
* template-haskell: Add putDoc, getDoc, withDecDoc and friendsLuke Lau2021-03-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | This adds two new methods to the Quasi class, putDoc and getDoc. They allow Haddock documentation to be added to declarations, module headers, function arguments and class/type family instances, as well as looked up. It works by building up a map of names to attach pieces of documentation to, which are then added in the extractDocs function in GHC.HsToCore.Docs. However because these template haskell names need to be resolved to GHC names at the time they are added, putDoc cannot directly add documentation to declarations that are currently being spliced. To remedy this, withDecDoc/withDecsDoc wraps the operation with addModFinalizer, and provides a more ergonomic interface for doing so. Similarly, the funD_doc, dataD_doc etc. combinators provide a more ergonomic interface for documenting functions and their arguments simultaneously. This also changes ArgDocMap to use an IntMap rather than an Map Int, for efficiency. Part of the work towards #5467
* The Char kind (#11342)Daniel Rogozin2021-02-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | Co-authored-by: Rinat Stryungis <rinat.stryungis@serokell.io> Implement GHC Proposal #387 * Parse char literals 'x' at the type level * New built-in type families CmpChar, ConsSymbol, UnconsSymbol * New KnownChar class (cf. KnownSymbol and KnownNat) * New SomeChar type (cf. SomeSymbol and SomeNat) * CharTyLit support in template-haskell Updated submodules: binary, haddock. Metric Decrease: T5205 haddock.base Metric Increase: Naperian T13035
* Implement type applications in patternsCale Gibbard2020-12-141-0/+8
| | | | | The haddock submodule is also updated so that it understands the changes to patterns.
* Use a newtype `Code` for the return type of typed quotations (Proposal #195)Matthew Pickering2020-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are three problems with the current API: 1. It is hard to properly write instances for ``Quote m => m (TExp a)`` as the type is the composition of two type constructors. Doing so in your program involves making your own newtype and doing a lot of wrapping/unwrapping. For example, if I want to create a language which I can either run immediately or generate code from I could write the following with the new API. :: class Lang r where _int :: Int -> r Int _if :: r Bool -> r a -> r a -> r a instance Lang Identity where _int = Identity _if (Identity b) (Identity t) (Identity f) = Identity (if b then t else f) instance Quote m => Lang (Code m) where _int = liftTyped _if cb ct cf = [|| if $$cb then $$ct else $$cf ||] 2. When doing code generation it is common to want to store code fragments in a map. When doing typed code generation, these code fragments contain a type index so it is desirable to store them in one of the parameterised map data types such as ``DMap`` from ``dependent-map`` or ``MapF`` from ``parameterized-utils``. :: compiler :: Env -> AST a -> Code Q a data AST a where ... data Ident a = ... type Env = MapF Ident (Code Q) newtype Code m a = Code (m (TExp a)) In this example, the ``MapF`` maps an ``Ident String`` directly to a ``Code Q String``. Using one of these map types currently requires creating your own newtype and constantly wrapping every quotation and unwrapping it when using a splice. Achievable, but it creates even more syntactic noise than normal metaprogramming. 3. ``m (TExp a)`` is ugly to read and write, understanding ``Code m a`` is easier. This is a weak reason but one everyone can surely agree with. Updates text submodule.
* Implement the proposed -XQualifiedDo extensionMatthias Pall Gissurarson2020-06-261-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Co-authored-by: Facundo Domínguez <facundo.dominguez@tweag.io> QualifiedDo is implemented using the same placeholders for operation names in the AST that were devised for RebindableSyntax. Whenever the renamer checks which names to use for do syntax, it first checks if the do block is qualified (e.g. M.do { stmts }), in which case it searches for qualified names in the module M. This allows users to write {-# LANGUAGE QualifiedDo #-} import qualified SomeModule as M f x = M.do -- desugars to: y <- M.return x -- M.return x M.>>= \y -> M.return y -- M.return y M.>> M.return y -- M.return y See Note [QualifiedDo] and the users' guide for more details. Issue #18214 Proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst Since we change the constructors `ITdo` and `ITmdo` to carry the new module name, we need to bump the haddock submodule to account or the new shape of these constructors.
* Linear types (#15981)Krzysztof Gogolewski2020-06-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Explicit SpecificityGert-Jan Bottu2020-05-211-16/+19
| | | | | | | | | | | | | | | | | | | | 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
* Add explicit LANGUAGE Safe to template-haskellOleg Grenrus2020-02-141-0/+2
| | | (cherry picked from commit a5e0f376821ca882880b03b07b451aa574e289ec)
* Overloaded Quotation Brackets (#246)Matthew Pickering2020-01-121-39/+39
| | | | | | | | | | | | | | | | | | This patch implements overloaded quotation brackets which generalise the desugaring of all quotation forms in terms of a new minimal interface. The main change is that a quotation, for example, [e| 5 |], will now have type `Quote m => m Exp` rather than `Q Exp`. The `Quote` typeclass contains a single method for generating new names which is used when desugaring binding structures. The return type of functions from the `Lift` type class, `lift` and `liftTyped` have been restricted to `forall m . Quote m => m Exp` rather than returning a result in a Q monad. More details about the feature can be read in the GHC proposal. https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0246-overloaded-bracket.rst
* Standalone kind signatures (#16794)wip/top-level-kind-signaturesVladislav Zavialov2019-09-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst With this patch, a type constructor can now be given an explicit standalone kind signature: {-# LANGUAGE StandaloneKindSignatures #-} type Functor :: (Type -> Type) -> Constraint class Functor f where fmap :: (a -> b) -> f a -> f b This is a replacement for CUSKs (complete user-specified kind signatures), which are now scheduled for deprecation. User-facing changes ------------------- * A new extension flag has been added, -XStandaloneKindSignatures, which implies -XNoCUSKs. * There is a new syntactic construct, a standalone kind signature: type <name> :: <kind> Declarations of data types, classes, data families, type families, and type synonyms may be accompanied by a standalone kind signature. * A standalone kind signature enables polymorphic recursion in types, just like a function type signature enables polymorphic recursion in terms. This obviates the need for CUSKs. * TemplateHaskell AST has been extended with 'KiSigD' to represent standalone kind signatures. * GHCi :info command now prints the kind signature of type constructors: ghci> :info Functor type Functor :: (Type -> Type) -> Constraint ... Limitations ----------- * 'forall'-bound type variables of a standalone kind signature do not scope over the declaration body, even if the -XScopedTypeVariables is enabled. See #16635 and #16734. * Wildcards are not allowed in standalone kind signatures, as partial signatures do not allow for polymorphic recursion. * Associated types may not be given an explicit standalone kind signature. Instead, they are assumed to have a CUSK if the parent class has a standalone kind signature and regardless of the -XCUSKs flag. * Standalone kind signatures do not support multiple names at the moment: type T1, T2 :: Type -> Type -- rejected type T1 = Maybe type T2 = Either String See #16754. * Creative use of equality constraints in standalone kind signatures may lead to GHC panics: type C :: forall (a :: Type) -> a ~ Int => Constraint class C a where f :: C a => a -> Int See #16758. Implementation notes -------------------- * The heart of this patch is the 'kcDeclHeader' function, which is used to kind-check a declaration header against its standalone kind signature. It does so in two rounds: 1. check user-written binders 2. instantiate invisible binders a la 'checkExpectedKind' * 'kcTyClGroup' now partitions declarations into declarations with a standalone kind signature or a CUSK (kinded_decls) and declarations without either (kindless_decls): * 'kinded_decls' are kind-checked with 'checkInitialKinds' * 'kindless_decls' are kind-checked with 'getInitialKinds' * DerivInfo has been extended with a new field: di_scoped_tvs :: ![(Name,TyVar)] These variables must be added to the context in case the deriving clause references tcTyConScopedTyVars. See #16731.
* Fix #15843 by extending Template Haskell AST for tuples to support sectionsnineonine2019-07-021-0/+12
|
* TH: support raw bytes literals (#14741)Sylvain Henry2019-03-081-1/+17
| | | | | | | | | | | | | | | | | | | GHC represents String literals as ByteString internally for efficiency reasons. However, until now it wasn't possible to efficiently create large string literals with TH (e.g. to embed a file in a binary, cf #14741): TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack into a ByteString. This patch adds the possibility to efficiently create a "string" literal from raw bytes. We get the following compile times for different sizes of TH created literals: || Size || Before || After || Gain || || 30K || 2.307s || 2.299 || 0% || || 3M || 3.073s || 2.400s || 21% || || 30M || 8.517s || 3.390s || 60% || Ticket #14741 can be fixed if the original code uses this new TH feature.
* Visible dependent quantificationRyan Scott2019-03-011-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide.
* Visible kind applicationmynguyen2019-01-031-11/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-271-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the user to explicitly bind type/kind variables in type and data family instances (including associated instances), closed type family equations, and RULES pragmas. Follows the specification of GHC Proposal 0007, also fixes #2600. Advised by Richard Eisenberg. This modifies the Template Haskell AST -- old code may break! Other Changes: - convert HsRule to a record - make rnHsSigWcType more general - add repMaybe to DsMeta Includes submodule update for Haddock. Test Plan: validate Reviewers: goldfire, bgamari, alanz Subscribers: simonpj, RyanGlScott, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #2600, #14268 Differential Revision: https://phabricator.haskell.org/D4894
* Add support for ImplicitParams and RecursiveDo in THMichael Sloan2018-09-141-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds TH support for the ImplicitParams and RecursiveDo extensions. I'm submitting this as one review because I cannot cleanly make the two commits independent. Initially, my goal was just to add ImplicitParams support, and I found that reasonably straightforward, so figured I might as well use my newfound knowledge to address some other TH omissions. Test Plan: Validate Reviewers: goldfire, austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: carter, RyanGlScott, thomie GHC Trac Issues: #1262 Differential Revision: https://phabricator.haskell.org/D1979
* Modifications to support loading GHC into GHCiMichael Sloan2018-07-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change was previously part of [D4904](https://phabricator.haskell.org/D4904), but is being split off to aid in getting this reviewed and merged. * The compiler code is built with `NoImplicitPrelude`, but GHCi's modules are incompatible with it. So, this adds the pragma to all GHCi modules that didn't have it, and adds imports of Prelude. * In order to run GHC within itself, a `call of 'initGCStatistics` needed to be skipped. This uses CPP to skip it when `-DGHC_LOADED_INTO_GHCI` is set. * There is an environment variable workaround suggested by Ben Gamari [1], where `_GHC_TOP_DIR` can be used to specify GHC's top dir if `-B` isn't provided. This can be used to solve a problem where the GHC being run within GHCi attempts to look in `inplace/lib/lib/` instead of `inplace/lib/`. [1]: https://phabricator.haskell.org/D4904#135438 Reviewers: goldfire, bgamari, erikd, alpmestan Reviewed By: alpmestan Subscribers: alpmestan, lelf, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4986
* Introduce DerivingViaRyan Scott2018-06-041-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the `DerivingVia` proposal put forth in https://github.com/ghc-proposals/ghc-proposals/pull/120. This introduces the `DerivingVia` deriving strategy. This is a generalization of `GeneralizedNewtypeDeriving` that permits the user to specify the type to `coerce` from. The major change in this patch is the introduction of the `ViaStrategy` constructor to `DerivStrategy`, which takes a type as a field. As a result, `DerivStrategy` is no longer a simple enumeration type, but rather something that must be renamed and typechecked. The process by which this is done is explained more thoroughly in section 3 of this paper ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ), although I have inlined the relevant parts into Notes where possible. There are some knock-on changes as well. I took the opportunity to do some refactoring of code in `TcDeriv`, especially the `mkNewTypeEqn` function, since it was bundling all of the logic for (1) deriving instances for newtypes and (2) `GeneralizedNewtypeDeriving` into one huge broth. `DerivingVia` reuses much of part (2), so that was factored out as much as possible. Bumps the Haddock submodule. Test Plan: ./validate Reviewers: simonpj, bgamari, goldfire, alanz Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #15178 Differential Revision: https://phabricator.haskell.org/D4684
* template-haskell: Rip out FamFlavourBen Gamari2017-12-041-2/+1
| | | | | This was scheduled to happen for 8.2, it looks like it will actually happen in 8.4.
* Merge types and kinds in DsMetaRyan Scott2017-07-281-788/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Types and kinds are now the same in GHC... well, except in the code that involves Template Haskell, where types and kinds are given separate treatment. This aims to unify that treatment in the `DsMeta` module. The gist of this patch is replacing all uses of `repLKind` with `repLTy`. This is isn't quite as simple as one might imagine, since `repLTy` returns a `Core (Q Type)` (a monadic expression), whereas `repLKind` returns a `Core Kind` (a pure expression). This causes many awkward impedance mismatches. One option would be to change every combinator in `Language.Haskell.TH.Lib` to take `KindQ` as an argument instead of `Kind`. But this would be a breaking change of colossal proportions. Instead, this patch takes a somewhat different approach. This migrates the existing `Language.Haskell.TH.Lib` module to `Language.Haskell.TH.Lib.Internal`, and changes all `Kind`-related combinators in `Language.Haskell.TH.Lib.Internal` to live in `Q`. The new `Language.Haskell.TH.Lib` module then re-exports most of `Language.Haskell.TH.Lib.Internal` with the exception of the `Kind`-related combinators, for which it redefines them to be their current definitions (which don't live in `Q`). This allows us to retain backwards compatibility with previous `template-haskell` releases, but more importantly, it allows GHC to make as many changes to the `Internal` code as it wants for its purposes without fear of disrupting the public API. This solves half of #11785 (the other half being `TcSplice`). Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #11785 Differential Revision: https://phabricator.haskell.org/D3751
* Add Template Haskell support for overloaded labelsMatthew Pickering2017-07-111-1/+4
| | | | | | | | | | Reviewers: RyanGlScott, austin, goldfire, bgamari Reviewed By: RyanGlScott, goldfire, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3715
* configure.ac: Bump version to 8.3ghc-8.3-startBen Gamari2017-03-091-1/+1
| | | | Bumps haddock submodule
* Template Haskell support for COMPLETE pragmasMatthew Pickering2017-01-261-1/+4
| | | | | | | | | | Reviewers: RyanGlScott, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2997 GHC Trac Issues: #13098
* Reexport Language.Haskell.TH.Lib from Language.Haskell.THRyan Scott2016-12-171-1/+103
| | | | | | | | | | | | | | | | | | | | Reexporting `Language.Haskell.TH.Lib` from `Language.Haskell.TH` ensures that `Language.Haskell.TH` will continue to expose all of the functions that `Language.Haskell.TH.Lib` does in the future. Fixes #12992. Test Plan: ./validate Reviewers: austin, bgamari, goldfire Reviewed By: bgamari, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2867 GHC Trac Issues: #12992
* Implement deriving strategiesRyan Scott2016-09-301-10/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allows users to explicitly request which approach to `deriving` to use via keywords, e.g., ``` newtype Foo = Foo Bar deriving Eq deriving stock Ord deriving newtype Show ``` Fixes #10598. Updates haddock submodule. Test Plan: ./validate Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin, erikd, simonmar Reviewed By: alanz, bgamari, simonpj Subscribers: thomie, mpickering, oerjan Differential Revision: https://phabricator.haskell.org/D2280 GHC Trac Issues: #10598
* Template Haskell support for TypeApplicationsRyan Scott2016-08-291-0/+3
| | | | | | | | | | | | | | | | Summary: Fixes #12530. Test Plan: make test TEST=12530 Reviewers: austin, bgamari, hvr, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2472 GHC Trac Issues: #12530
* Template Haskell support for unboxed sumsRyan Scott2016-08-231-0/+13
| | | | | | | | | | | | | | | | | | | | | | | This adds new constructors `UnboxedSumE`, `UnboxedSumT`, and `UnboxedSumP` to represent unboxed sums in Template Haskell. One thing you can't currently do is, e.g., `reify ''(#||#)`, since I don't believe unboxed sum type/data constructors can be written in prefix form. I will look at fixing that as part of #12514. Fixes #12478. Test Plan: make test TEST=T12478_{1,2,3} Reviewers: osa1, goldfire, austin, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2448 GHC Trac Issues: #12478
* Add TH support for pattern synonyms (fixes #8761)Dominik Bollmann2016-05-121-2/+37
| | | | | | | | | | | | | | | | | | This commit adds Template Haskell support for pattern synonyms as requested by trac ticket #8761. Test Plan: ./validate Reviewers: thomie, jstolarek, osa1, RyanGlScott, mpickering, austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: rdragon Differential Revision: https://phabricator.haskell.org/D1940 GHC Trac Issues: #8761
* Add TemplateHaskell support for Overlapping pragmasIavor S. Diatchki2016-04-171-2/+7
| | | | | | | | | | Reviewers: hvr, goldfire, austin, RyanGlScott, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D2118
* TemplateHaskell: revive isStrict, notStrict and unpackedThomas Miedema2016-01-131-0/+14
| | | | | | | | | | | | | These 3 functions are useful to keep around a bit longer, to prevent breaking existing code that uses them. Related to #10697. Reviewers: austin, goldfire, RyanGlScott, bgamari Reviewed By: RyanGlScott, bgamari Differential Revision: https://phabricator.haskell.org/D1761
* Change Template Haskell representation of GADTs.Jan Stolarek2016-01-061-7/+5
| | | | | | | | | | | | | | | Previous representation of GADTs in TH was not expressive enough to express possible GADT return types. See #11341 Test Plan: ./validate Reviewers: goldfire, austin, bgamari Subscribers: thomie, RyanGlScott Differential Revision: https://phabricator.haskell.org/D1738 GHC Trac Issues: #11341
* Bump GHC HEAD's Version from 7.11 to 8.1ghc-8.1-startHerbert Valerio Riedel2015-12-301-1/+1
| | | | This updates the haddock submodule
* Update a few references to GHC 7.12Ben Gamari2015-12-291-1/+1
|
* Refactor named wildcards (again)Simon Peyton Jones2015-12-221-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Michal's work on #10982, #11098, refactored the handling of named wildcards by making them more like ordinary type variables. This patch takes the same idea to its logical conclusion, resulting in a much tidier, tighter implementation. Read Note [The wildcard story for types] in HsTypes. Changes: * Named wildcards are ordinary type variables, throughout * HsType no longer has a data constructor for named wildcards (was NamedWildCard in HsWildCardInfo). Named wildcards are simply HsTyVars * Similarly named wildcards disappear from Template Haskell * I refactored RnTypes to avoid polluting LocalRdrEnv with something as narrow as named wildcards. Instead the named wildcard set is carried in RnTyKiEnv. There is a submodule update for Haddock.
* Rework Template Haskell's handling of strictnessRyanGlScott2015-12-221-35/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, Template Haskell's treatment of strictness is not enough to cover all possible combinations of unpackedness and strictness. In addition, it isn't equipped to deal with new features (such as `-XStrictData`) which can change a datatype's fields' strictness during compilation. To address this, I replaced TH's `Strict` datatype with `SourceUnpackedness` and `SourceStrictness` (which give the programmer a more complete toolkit to configure a datatype field's strictness than just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to reify a constructor fields' strictness post-compilation through the `reifyConStrictness` function. Fixes #10697. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari, austin Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1603 GHC Trac Issues: #10697
* Add proper GADTs support to Template HaskellJan Stolarek2015-12-211-13/+20
| | | | | | | | | | | | | | | | Until now GADTs were supported in Template Haskell by encoding them using normal data types. This patch adds proper support for representing GADTs in TH. Test Plan: T10828 Reviewers: goldfire, austin, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1465 GHC Trac Issues: #10828
* Fix-up GHC 7.12 artifactsHerbert Valerio Riedel2015-12-211-1/+1
| | | | | The haddock submodule also still assumed that GHC 7.12 would be the next major release (rather than GHC 8.0)
* Use Cxt for deriving clauses in TH (#10819)Ben Gamari2015-12-141-8/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: Deriving clauses in the TH representations of data, newtype, data instance, and newtype instance declarations previously were just [Name], which didn't allow for more complex derived classes, eg. multi-parameter typeclasses. This switches out [Name] for Cxt, representing the derived classes as types instead of names. Test Plan: validate Reviewers: goldfire, spinda, austin Reviewed By: goldfire, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1202 GHC Trac Issues: #10819
* Refactor type families in Template HaskellJohn Leo2015-12-121-6/+8
| | | | | | | | | | | | | | | | Fixes #10902. Test Plan: validate Reviewers: goldfire, austin, hvr, jstolarek, bgamari Reviewed By: jstolarek, bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1570 GHC Trac Issues: #10902
* Add typed holes support in Template Haskell.Jan Stolarek2015-10-161-0/+3
| | | | | Fixes #10267. Typed holes in typed Template Haskell currently don't work. See #10945 and #10946.
* Injective type familiesJan Stolarek2015-09-031-18/+68
| | | | | | | | | | | | | | | | | | | For details see #6018, Phab:D202 and the wiki page: https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies This patch also wires-in Maybe data type and updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar, carter Differential Revision: https://phabricator.haskell.org/D202 GHC Trac Issues: #6018
* Add UInfixT to TH types (fixes #10522)Michael Smith2015-07-271-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | UInfixT is like UInfixE or UInfixP but for types. Template Haskell splices can use it to punt fixity handling to GHC when constructing types. UInfixT is converted in compiler/hsSyn/Convert to a right-biased tree of HsOpTy, which is already rearranged in compiler/rename/RnTypes to match operator fixities. This patch consists of (1) adding UInfixT to the AST, (2) implementing the conversion and updating relevant comments, (3) updating pretty-printing and library support, and (4) adding tests. Test Plan: validate Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1088 GHC Trac Issues: #10522
* Support wild cards in TH splicesThomas Winant2015-07-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Declaration splices: partial type signatures are fully supported in TH declaration splices. For example, the wild cards in the example below will unify with `Eq a` and `a -> a -> Bool`, as expected: ``` [d| foo :: _ => _ foo x y = x == y |] ``` - Expression splices: anonymous and named wild cards are supported in expression signatures, but extra-constraints wild cards aren't. Just as is the case for regular expression signatures. ``` [e | Just True :: _a _ |] ``` - Typed expression splices: the same wildcards as in (untyped) expression splices are supported. - Pattern splices: TH doesn't support type signatures in pattern splices, consequently, partial type signatures aren't supported either. - Type splices: partial type signatures are only partially supported in type splices, specifically: only anonymous wild cards are allowed. So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as the named wild card is treated as a type variable). Normally, named wild cards are collected before renaming a (partial) type signature. However, TH type splices are run during renaming, i.e. after the initial traversal, leading to out of scope errors for named wild cards. We can't just extend the initial traversal to collect the named wild cards in TH type splices, as we'd need to expand them, which is supposed to happen only once, during renaming. Similarly, the extra-constraints wild card is handled right before renaming too, and is therefore also not supported in a TH type splice. Another reason not to support extra-constraints wild cards in TH type splices is that a single signature can contain many TH type splices, whereas it mustn't contain more than one extra-constraints wild card. Enforcing would this be hard the way things are currently organised. Anonymous wild cards pose no problem, because they start without names and are given names during renaming. These names are collected right after renaming. The names generated for anonymous wild cards in TH type splices will thus be collected as well. With a more invasive refactoring of the renaming, partial type signatures could be fully supported in TH type splices. As only anonymous wild cards have been requested so far, these small changes satisfying this request will do for now. Also don't forget that a TH declaration splices support all kinds of wild cards. - Extra-constraints wild cards were silently ignored in expression and pattern signatures, appropriate error messages are now generated. Test Plan: run new tests Reviewers: austin, goldfire, adamgundry, bgamari Reviewed By: goldfire, adamgundry, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1048 GHC Trac Issues: #10094, #10548
View Lorry Controller Status