summaryrefslogtreecommitdiff
path: root/compiler/iface/BuildTyCl.lhs
Commit message (Collapse)AuthorAgeFilesLines
* De-tabify and remove trailing whitespaceSimon Peyton Jones2014-09-261-149/+143
|
* Comments and white spaceSimon Peyton Jones2014-08-071-1/+1
|
* Assert that matcher-derived PatSyn types match the (redundant) stored types ↵Dr. ERDI Gergo2014-05-271-7/+12
| | | | in IfacePatSyn
* Store IfExtNames for PatSyn matchers and wrappers in interface file.Dr. ERDI Gergo2014-05-271-60/+21
| | | | | | | This way, the Ids for the matchers/wrappers are reused by importing modules, and thus unfoldings are kept. Also updates haddock submodule to accomodate tweaks in PatSyn representation
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-1/+2
| | | | | | | | | | | | | | | | | | 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.
* Refactor buildClass and mkDictSelId a bit, to avoid the no_unf argumentSimon Peyton Jones2014-05-081-10/+5
| | | | | No change in functionality, just a cleaner story, with the RHS for dictionary selectors being treated less specially than before.
* Implement pattern synonymsDr. ERDI Gergo2014-01-201-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Move defaultClassMinimalDef from BuildTyCl to TcClassDclunknown2013-10-011-11/+1
| | | | | | | Simple refactoring. Also in Vectorise.Types/TyConDecl, simply propagate the classMinimalDef from the class we are vectorising. Simpler and more direct.
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-1/+1
|
* Implement checkable "minimal complete definitions" (#7633)Twan van Laarhoven2013-09-181-3/+14
| | | | | | | | | | | | | | This commit adds a `{-# MINIMAL #-}` pragma, which defines the possible minimal complete definitions for a class. The body of the pragma is a boolean formula of names. The old warning for missing methods is replaced with this new one. Note: The interface file format is changed to store the minimal complete definition. Authored-by: Twan van Laarhoven <twanvl@gmail.com> Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Implement "roles" into GHC.Richard Eisenberg2013-08-021-20/+23
| | | | | | | | | | | | | | | | Roles are a solution to the GeneralizedNewtypeDeriving type-safety problem. Roles were first described in the "Generative type abstraction" paper, by Stephanie Weirich, Dimitrios Vytiniotis, Simon PJ, and Steve Zdancewic. The implementation is a little different than that paper. For a quick primer, check out Note [Roles] in Coercion. Also see http://ghc.haskell.org/trac/ghc/wiki/Roles and http://ghc.haskell.org/trac/ghc/wiki/RolesImplementation For a more formal treatment, check out docs/core-spec/core-spec.pdf. This fixes Trac #1496, #4846, #7148.
* Revise implementation of overlapping type family instances.Richard Eisenberg2013-06-211-1/+1
| | | | | | | | | | | | | | | | | | | 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.
* Refactor and improve the promotion inferenceSimon Peyton Jones2013-01-251-16/+0
| | | | | | | | | | | | | | | | | | It should be the case that either an entire mutually recursive group of data type declarations can be promoted, or none of them. It's really odd to promote some data constructors of a type but not others. Eg data T a = T1 a | T2 Int Here T1 is sort-of-promotable but T2 isn't (becuase Int isn't promotable). This patch makes it all-or-nothing. At the same time I've made the TyCon point to its promoted cousin (via the tcPromoted field of an AlgTyCon), as well as vice versa (via the ty_con field of PromotedTyCon). The inference for the group is done in TcTyDecls, the same place that infers which data types are recursive, another global question.
* Make {-# UNPACK #-} work for type/data family invocationsSimon Peyton Jones2012-12-231-5/+7
| | | | | | | | | | | | | | | | | | | | | 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.
* Major refactoring of the way that UNPACK pragmas are handledSimon Peyton Jones2012-12-141-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The situation was pretty dire. The way in which data constructors were handled, notably the mapping between their *source* argument types and their *representation* argument types (after seq'ing and unpacking) was scattered in three different places, and hard to keep in sync. Now it is all in one place: * The dcRep field of a DataCon gives its representation, specified by a DataConRep * As well as having the wrapper, the DataConRep has a "boxer" of type DataConBoxer (defined in MkId for loopy reasons). The boxer used at a pattern match to reconstruct the source-level arguments from the rep-level bindings in the pattern match. * The unboxing in the wrapper and the boxing in the boxer are dual, and are now constructed together, by MkId.mkDataConRep. This is the key function of this change. * All the computeBoxingStrategy code in TcTyClsDcls disappears. Much nicer. There is a little bit of refactoring left to do; the strange deepSplitProductType functions are now called only in WwLib, so I moved them there, and I think they could be tidied up further.
* Make the opt_UF_* static flags dynamicIan Lynagh2012-10-091-3/+7
| | | | | | | | I also removed the default values from the "Discounts and thresholds" note: most of them were no longer up-to-date. Along the way I added FloatSuffix to the argument parser, analogous to IntSuffix.
* Make a start towards eta-rules and injective familiesSimon Peyton Jones2012-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | * 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.
* Change how macros like ASSERT are definedIan Lynagh2012-06-051-1/+1
| | | | | By using Haskell's debugIsOn rather than CPP's "#ifdef DEBUG", we don't need to kludge things to keep the warning checker happy etc.
* Add a crucial forkM on the superclass context of IfaceClass in tcIfaceDeclSimon Peyton Jones2012-03-281-4/+3
| | | | | | | | | The absence of this was causing a loop when typechecking an interface where the superclass context mentioned an associated type class C (T a) => D a where data T a Fixes Trac #5970
* Remove support for CTYPE pragmas on type synonymsIan Lynagh2012-02-221-3/+2
| | | | | | It's not clear whether it's desirable or not, and it turns out that the way we use coercions in GHC means we tend to lose information about type synonyms.
* Implement the CTYPE pragma; part of the CApiFFI extensionIan Lynagh2012-02-161-4/+7
| | | | | | | For now, the syntax is type {-# CTYPE "some C type" #-} Foo = ... newtype {-# CTYPE "some C type" #-} Foo = ... data {-# CTYPE "some C type" #-} Foo = ...
* Give promoted DataCons a tyConArity and promoted TyCons a tyConKindSimon Peyton Jones2012-02-061-8/+0
| | | | ..and fix up Core Lint. (I was getting a bogus Core Lint failure.)
* Major refactoring of CoAxiomsSimon Peyton Jones2012-01-031-58/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch should have no user-visible effect. It implements a significant internal refactoring of the way that FC axioms are handled. The ultimate goal is to put us in a position to implement "pattern-matching axioms". But the changes here are only does refactoring; there is no change in functionality. Specifically: * We now treat data/type family instance declarations very, very similarly to types class instance declarations: - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with FamInstEnv.FamInst. This change does affect the GHC API, but for the better I think. - Previously, each family type/data instance declaration gave rise to a *TyCon*; typechecking a type/data instance decl produced that TyCon. Now, each type/data instance gives rise to a *FamInst*, by direct analogy with each class instance declaration giving rise to a ClsInst. - Just as each ClsInst contains its evidence, a DFunId, so each FamInst contains its evidence, a CoAxiom. See Note [FamInsts and CoAxioms] in FamInstEnv. The CoAxiom is a System-FC thing, and can relate any two types, whereas the FamInst relates directly to the Haskell source language construct, and always has a function (F tys) on the LHS. - Just as a DFunId has its own declaration in an interface file, so now do CoAxioms (see IfaceSyn.IfaceAxiom). These changes give rise to almost all the refactoring. * We used to have a hack whereby a type family instance produced a dummy type synonym, thus type instance F Int = Bool -> Bool translated to axiom FInt :: F Int ~ R:FInt type R:FInt = Bool -> Bool This was always a hack, and now it's gone. Instead the type instance declaration produces a FamInst, whose axiom has kind axiom FInt :: F Int ~ Bool -> Bool just as you'd expect. * Newtypes are done just as before; they generate a CoAxiom. These CoAxioms are "implicit" (do not generate an IfaceAxiom declaration), unlike the ones coming from family instance declarations. See Note [Implicit axioms] in TyCon On the whole the code gets significantly nicer. There were consequential tidy-ups in the vectoriser, but I think I got them right.
* Move mkPiTypes back to Type, rename mkForAllArrowKinds to mkPiKindsJose Pedro Magalhaes2011-11-161-3/+3
|
* New kind-polymorphic coreJose Pedro Magalhaes2011-11-111-10/+16
| | | | | | | | | 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
* 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.
* Merge branch 'no-pred-ty'Max Bolingbroke2011-09-091-15/+12
|\ | | | | | | | | | | | | | | | | | | Conflicts: compiler/iface/BuildTyCl.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/types/Class.lhs compiler/utils/Util.lhs
| * Implement -XConstraintKindMax Bolingbroke2011-09-061-15/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* | Implement associated type defaultsMax Bolingbroke2011-09-091-4/+3
|/ | | | | | | | | | | | | | | | | | | 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
* Export a tiny bit more info with AbstractTyCon (fixes #5424)Simon Peyton Jones2011-09-021-3/+4
| | | | | | | | | | | | | | | | | | | | | | When we compile -O0 we put type constructors in the interface file without their data constructors -- an AbstractTyCon. But in a client module, to give good pattern-match exhaustiveness warnings, we need to know the difference between a data type and a newtype. (The latter can be coerced to another type, but a data type can't.) See Note [Pruning dead case alternatives] in Unify. Because we weren't conveying this info, we were getting bogus warnings about inexhaustive patterm matches with GADTs, and (confusingly) these warnings woudl come and go depending on whether you were compiling with -O. This patch makes AbstractTyCon carry a flag indicating whether the type constructor is "distinct"; two distinct TyCons cannot be coerced into eachother (except by unsafeCoerce, in which case all bets are off). HEADS UP: interface file format changes slightly, so you need to make clean.
* Add equality superclassesSimon Peyton Jones2011-06-221-27/+23
| | | | | | | | | | | | | | | | Hurrah. At last we can write class (F a ~ b) => C a b where { ... } This fruit of the fact that equalities are now values, and all evidence is handled uniformly. The main tricky point is that when translating to Core an evidence variable 'v' is represented either as either Var v or Coercion (CoVar v) depending on whether or not v is an equality. This leads to a few annoying calls to 'varToCoreExpr'.
* Rejig the way in which generic default method signatures are checkedSimon Peyton Jones2011-05-261-2/+2
| | | | | | | | - Check GenericSig in tcClassSigs, along with TypeSig - Add the generic default methods to the type envt - Look them up via tcLookupId in TcClassDcl.tcDefMeth Much nicer!
* Simon's fixes to the generated type instances in GenericsSimon Peyton Jones2011-05-201-1/+2
|
* Merge branch 'master' of http://darcs.haskell.org/ghc into ghc-genericsJose Pedro Magalhaes2011-05-121-14/+6
|\ | | | | | | | | Resolved conflicts: compiler/typecheck/TcTyClsDecls.lhs
| * This BIG PATCH contains most of the work for the New Coercion RepresentationSimon Peyton Jones2011-04-191-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | See the paper "Practical aspects of evidence based compilation in System FC" * Coercion becomes a data type, distinct from Type * Coercions become value-level things, rather than type-level things, (although the value is zero bits wide, like the State token) A consequence is that a coerion abstraction increases the arity by 1 (just like a dictionary abstraction) * There is a new constructor in CoreExpr, namely Coercion, to inject coercions into terms
* | Remove the hasGenerics field of TyCon, improve the way the Generics flags is ↵Jose Pedro Magalhaes2011-05-021-4/+3
| | | | | | | | handled, allow for standalone deriving of Representable0.
* | Initial commit for Pedro's new generic default methodssimonpj2011-04-121-3/+5
|/ | | | | (See his Haskell Symposium 2010 paper "A generic deriving mechaism for Haskell")
* Tighten up what it means to be an "enumeration data constructor"simonpj@microsoft.com2010-12-151-2/+6
| | | | See Note [Enumeration types] in TyCon, and comments in Trac #4528
* Comment on what an "enumeration" type issimonpj@microsoft.com2010-09-141-8/+2
|
* Super-monster patch implementing the new typechecker -- at lastsimonpj@microsoft.com2010-09-131-75/+63
| | | | | | | | | This major patch implements the new OutsideIn constraint solving algorithm in the typecheker, following our JFP paper "Modular type inference with local assumptions". Done with major help from Dimitrios Vytiniotis and Brent Yorgey.
* Comments and formatting to vectoriserbenl@ouroborus.net2010-08-301-10/+10
|
* Refactor (again) the handling of default methodssimonpj@microsoft.com2010-05-251-13/+24
| | | | | | | | | | | | | | | | | | This patch fixes Trac #4056, by a) tidying up the treatment of default method names b) removing the 'module' argument to newTopSrcBinder The details aren't that interesting, but the result is much tidier. The original bug was a 'nameModule' panic, caused by trying to find the module of a top-level name. But TH quotes generate Internal top-level names that don't have a module, and that is generally a good thing. Fixing that in turn led to the default-method refactoring, which also makes the Name for a default method be handled in the same way as other derived names, generated in BuildTyCl via a call newImplicitBinder. Hurrah.
* Fix Trac #3966: warn about useless UNPACK pragmassimonpj@microsoft.com2010-05-061-2/+2
| | | | | | | | | | | | Warning about useless UNPACK pragmas wasn't as easy as I thought. I did quite a bit of refactoring, which improved the code by refining the types somewhat. In particular notice that in DataCon, we have dcStrictMarks :: [HsBang] dcRepStrictness :: [StrictnessMarks] The former relates to the *source-code* annotation, the latter to GHC's representation choice.
* expand comments for #2578 fixSimon Marlow2010-03-011-1/+6
|
* Fix trac #2578Ian Lynagh2010-02-271-1/+7
| | | | | We define empty datatypes as not being enumerations, which means the empty blocks aren't generated.
* Remove unused importsIan Lynagh2009-07-071-3/+0
|
* Make record selectors into ordinary functionssimonpj@microsoft.com2009-01-021-21/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This biggish patch addresses Trac #2670. The main effect is to make record selectors into ordinary functions, whose unfoldings appear in interface files, in contrast to their previous existence as magic "implicit Ids". This means that the usual machinery of optimisation, analysis, and inlining applies to them, which was failing before when the selector was somewhat complicated. (Which it can be when strictness annotations, unboxing annotations, and GADTs are involved.) The change involves the following points * Changes in Var.lhs to the representation of Var. Now a LocalId can have an IdDetails as well as a GlobalId. In particular, the information that an Id is a record selector is kept in the IdDetails. While compiling the current module, the record selector *must* be a LocalId, so that it participates properly in compilation (free variables etc). This led me to change the (hidden) representation of Var, so that there is now only one constructor for Id, not two. * The IdDetails is persisted into interface files, so that an importing module can see which Ids are records selectors. * In TcTyClDecls, we generate the record-selector bindings in renamed, but not typechecked form. In this way, we can get the typechecker to add all the types and so on, which is jolly helpful especially when GADTs or type families are involved. Just like derived instance declarations. This is the big new chunk of 180 lines of code (much of which is commentary). A call to the same function, mkAuxBinds, is needed in TcInstDcls for associated types. * The typechecker therefore has to pin the correct IdDetails on to the record selector, when it typechecks it. There was a neat way to do this, by adding a new sort of signature to HsBinds.Sig, namely IdSig. This contains an Id (with the correct Name, Type, and IdDetails); the type checker uses it as the binder for the final binding. This worked out rather easily. * Record selectors are no longer "implicit ids", which entails changes to IfaceSyn.ifaceDeclSubBndrs HscTypes.implicitTyThings TidyPgm.getImplicitBinds (These three functions must agree.) * MkId.mkRecordSelectorId is deleted entirely, some 300+ lines (incl comments) of very error prone code. Happy days. * A TyCon no longer contains the list of record selectors: algTcSelIds is gone The renamer is unaffected, including the way that import and export of record selectors is handled. Other small things * IfaceSyn.ifaceDeclSubBndrs had a fragile test for whether a data constructor had a wrapper. I've replaced that with an explicit flag in the interface file. More robust I hope. * I renamed isIdVar to isId, which touched a few otherwise-unrelated files.
* Avoid nasty name clash with associated data types (fixes Trac #2888)simonpj@microsoft.com2008-12-301-1/+8
| | | | | | | | | | | | | The main bug was in TcHsType; see Note [Avoid name clashes for associated data types]. However I did a bit of re-factoring while I was abouut it. I'm still a but unhappy with the use of TyCon.setTyConArgPoss; it'd be better to construct the TyCon correctly in the first place. But that means passing an extra parameter to tcTyDecl1... maybe we should do this.
* Allow type families to use GADT syntax (and be GADTs)simonpj@microsoft.com2008-09-231-5/+7
| | | | | | | | | | | | | | We've always intended to allow you to use GADT syntax for data families: data instance T [a] where T1 :: a -> T [a] and indeed to allow data instances to *be* GADTs data intsance T [a] where T1 :: Int -> T [Int] T2 :: a -> b -> T [(a,b)] This patch fixes the renamer and type checker to allow this.
* Comments only: replace ":=:" by "~" (notation for equality predicates)simonpj@microsoft.com2008-09-201-1/+1
|
View Lorry Controller Status