summaryrefslogtreecommitdiff
path: root/compiler/iface/BinIface.hs
Commit message (Collapse)AuthorAgeFilesLines
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | See Note [TYPE] in TysPrim. There are still some outstanding pieces in #11471 though, so this doesn't actually nail the bug. This commit also contains a few performance improvements: * Short-cut equality checking of nullary type syns * Compare types before kinds in eqType * INLINE coreViewOneStarKind * Store tycon binders separately from kinds. This resulted in a ~10% performance improvement in compiling the Cabal package. No change in functionality other than performance. (This affects the interface file format, though.) This commit updates the haddock submodule.
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-141-2/+2
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* BinIface: Clean up whitespaceBen Gamari2015-08-261-3/+2
|
* Refactor tuple constraintsSimon Peyton Jones2015-05-181-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity - Haddock needs to absorb the change too; so there is a submodule update
* Revert multiple commitsAustin Seipp2015-05-141-6/+10
| | | | | | | | | | | | | | | | | | | | This reverts multiple commits from Simon: - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable-given" check happen first - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to checkValidTyCon - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet from fixVarSet - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain (stage2) - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the build - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation of error msg - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple constraints - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out line These break the build by causing Haddock to fail mysteriously when trying to examine GHC.Prim it seems.
* Refactor tuple constraintsSimon Peyton Jones2015-05-131-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make tuple constraints be handled by a perfectly ordinary type class, with the component constraints being the superclasses: class (c1, c2) => (c2, c2) This change was provoked by #10359 inability to re-use a given tuple constraint as a whole #9858 confusion between term tuples and constraint tuples but it's generally a very nice simplification. We get rid of - In Type, the TuplePred constructor of PredTree, and all the code that dealt with TuplePreds - In TcEvidence, the constructors EvTupleMk, EvTupleSel See Note [How tuples work] in TysWiredIn. Of course, nothing is ever entirely simple. This one proved quite fiddly. - I did quite a bit of renaming, which makes this patch touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. - I made constraint tuples known-key rather than wired-in. This is different to boxed/unboxed tuples, but it proved awkward to have all the superclass selectors wired-in. Easier just to use the standard mechanims. - While I was fiddling with known-key names, I split the TH Name definitions out of DsMeta into a new module THNames. That meant that the known-key names can all be gathered in PrelInfo, without causing module loops. - I found that the parser was parsing an import item like T( .. ) as a *data constructor* T, and then using setRdrNameSpace to fix it. Stupid! So I changed the parser to parse a *type constructor* T, which means less use of setRdrNameSpace. I also improved setRdrNameSpace to behave better on Exact Names. Largely on priciple; I don't think it matters a lot. - When compiling a data type declaration for a wired-in thing like tuples (,), or lists, we don't really need to look at the declaration. We have the wired-in thing! And not doing so avoids having to line up the uniques for data constructor workers etc. See Note [Declarations for wired-in things] - I found that FunDeps.oclose wasn't taking superclasses into account; easily fixed. - Some error message refactoring for invalid constraints in TcValidity
* Refactor TyCon to eliminate TupleTyConSimon Peyton Jones2015-05-011-10/+13
| | | | | | | | | | | | | This makes TupleTyCon into an ordinary AlgTyCon, distinguished by its AlgTyConRhs, rather than a separate constructor of TyCon. It is preparatory work for making constraint tuples into classes, for which the ConstraintTuple tuples will have a TyConParent of a ClassTyCon. Tuples didn't have this possiblity before. The patch affects other modules because I eliminated the unsatisfactory partial functions tupleTyConBoxity and tupleTyConSort. And tupleTyConArity which is just tyConArity.
* Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId.Edward Z. Yang2014-07-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, both Cabal and GHC defined the type PackageId, and we expected them to be roughly equivalent (but represented differently). This refactoring separates these two notions. A package ID is a user-visible identifier; it's the thing you write in a Cabal file, e.g. containers-0.9. The components of this ID are semantically meaningful, and decompose into a package name and a package vrsion. A package key is an opaque identifier used by GHC to generate linking symbols. Presently, it just consists of a package name and a package version, but pursuant to #9265 we are planning to extend it to record other information. Within a single executable, it uniquely identifies a package. It is *not* an InstalledPackageId, as the choice of a package key affects the ABI of a package (whereas an InstalledPackageId is computed after compilation.) Cabal computes a package key for the package and passes it to GHC using -package-name (now *extremely* misnamed). As an added bonus, we don't have to worry about shadowing anymore. As a follow on, we should introduce -current-package-key having the same role as -package-name, and deprecate the old flag. This commit is just renaming. The haddock submodule needed to be updated. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D79 Conflicts: compiler/main/HscTypes.lhs compiler/main/Packages.lhs utils/haddock
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-0/+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.
* Implement pattern synonymsDr. ERDI Gergo2014-01-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* simplified the .hi format and added the -flate-dmd-anal flag (fixes #7782)Nicolas Frisby2013-08-291-2/+0
| | | | cf http://ghc.haskell.org/trac/ghc/wiki/LateDmd
* Implement "roles" into GHC.Richard Eisenberg2013-08-021-0/+1
| | | | | | | | | | | | | | | | 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.
* De-orphan a load of Binary instancesIan Lynagh2013-07-271-1079/+0
|
* Revise implementation of overlapping type family instances.Richard Eisenberg2013-06-211-13/+14
| | | | | | | | | | | | | | | | | | | 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.
* Make 'SPECIALISE instance' work againSimon Peyton Jones2013-05-301-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a long-standing regression (Trac #7797), which meant that in particular the Eq [Char] instance does not get specialised. (The *methods* do, but the dictionary itself doesn't.) So when you call a function f :: Eq a => blah on a string type (ie a=[Char]), 7.6 passes a dictionary of un-specialised methods. This only matters when calling an overloaded function from a specialised context, but that does matter in some programs. I remember (though I cannot find the details) that Nick Frisby discovered this to be the source of some pretty solid performanc regresisons. Anyway it works now. The key change is that a DFunUnfolding now takes a form that is both simpler than before (the DFunArg type is eliminated) and more general: data Unfolding = ... | DFunUnfolding { -- The Unfolding of a DFunId -- See Note [DFun unfoldings] -- df = /\a1..am. \d1..dn. MkD t1 .. tk -- (op1 a1..am d1..dn) -- (op2 a1..am d1..dn) df_bndrs :: [Var], -- The bound variables [a1..m],[d1..dn] df_con :: DataCon, -- The dictionary data constructor (never a newtype datacon) df_args :: [CoreExpr] -- Args of the data con: types, superclasses and methods, } -- in positional order That in turn allowed me to re-enable the DFunUnfolding specialisation in DsBinds. Lots of details here in TcInstDcls: Note [SPECIALISE instance pragmas] I also did some refactoring, in particular to pass the InScopeSet to exprIsConApp_maybe (which in turn means it has to go to a RuleFun). NB: Interface file format has changed!
* Change a few throwGhcException uses to throwGhcExceptionIOIan Lynagh2013-01-301-1/+1
|
* More refactoring of FamInst/FamInstEnv; finally fixes Trac #7524Simon Peyton Jones2013-01-281-7/+0
| | | | | | | | | | | | | | | | | | | | | | Quite a bit of tidying up here; the fix to #7524 is actually only a small part. * Be fully clear that the cab_tvs in a CoAxBranch are not fresh. See Note [CoAxBranch type variables] in CoAxiom. * Use CoAxBranch to replace the ATDfeault type in Class. CoAxBranch is perfect here. This change allowed me to delete quite a bit of boilerplate code, including the corresponding IfaceSynType. * Tidy up the construction of CoAxBranches, and when FamIntBranch is freshened. The latter onw happens only in FamInst.newFamInst. * Tidy the tyvars of a CoAxBranch when we build them, done in FamInst.mkCoAxBranch. See Note [Tidy axioms when we build them] in that module. This is what fixes #7524. Much niceer now.
* Merge branch 'master' of http://darcs.haskell.org/ghcSimon Peyton Jones2013-01-251-95/+5
|\
| * Major patch to implement the new Demand AnalyserSimon Peyton Jones2013-01-171-95/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is the result of Ilya Sergey's internship at MSR. It constitutes a thorough overhaul and simplification of the demand analyser. It makes a solid foundation on which we can now build. Main changes are * Instead of having one combined type for Demand, a Demand is now a pair (JointDmd) of - a StrDmd and - an AbsDmd. This allows strictness and absence to be though about quite orthogonally, and greatly reduces brain melt-down. * Similarly in the DmdResult type, it's a pair of - a PureResult (indicating only divergence/non-divergence) - a CPRResult (which deals only with the CPR property * In IdInfo, the strictnessInfo field contains a StrictSig, not a Maybe StrictSig demandInfo field contains a Demand, not a Maybe Demand We don't need Nothing (to indicate no strictness/demand info) any more; topSig/topDmd will do. * Remove "boxity" analysis entirely. This was an attempt to avoid "reboxing", but it added complexity, is extremely ad-hoc, and makes very little difference in practice. * Remove the "unboxing strategy" computation. This was an an attempt to ensure that a worker didn't get zillions of arguments by unboxing big tuples. But in fact removing it DRAMATICALLY reduces allocation in an inner loop of the I/O library (where the threshold argument-count had been set just too low). It's exceptional to have a zillion arguments and I don't think it's worth the complexity, especially since it turned out to have a serious performance hit. * Remove quite a bit of ad-hoc cruft * Move worthSplittingFun, worthSplittingThunk from WorkWrap to Demand. This allows JointDmd to be fully abstract, examined only inside Demand. Everything else really follows from these changes. All of this is really just refactoring, so we don't expect big performance changes, but acutally the numbers look quite good. Here is a full nofib run with some highlights identified: Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- expert -2.6% -15.5% 0.00 0.00 +0.0% fluid -2.4% -7.1% 0.01 0.01 +0.0% gg -2.5% -28.9% 0.02 0.02 -33.3% integrate -2.6% +3.2% +2.6% +2.6% +0.0% mandel2 -2.6% +4.2% 0.01 0.01 +0.0% nucleic2 -2.0% -16.3% 0.11 0.11 +0.0% para -2.6% -20.0% -11.8% -11.7% +0.0% parser -2.5% -17.9% 0.05 0.05 +0.0% prolog -2.6% -13.0% 0.00 0.00 +0.0% puzzle -2.6% +2.2% +0.8% +0.8% +0.0% sorting -2.6% -35.9% 0.00 0.00 +0.0% treejoin -2.6% -52.2% -9.8% -9.9% +0.0% -------------------------------------------------------------------------------- Min -2.7% -52.2% -11.8% -11.7% -33.3% Max -1.8% +4.2% +10.5% +10.5% +7.7% Geometric Mean -2.5% -2.8% -0.4% -0.5% -0.4% Things to note * Binary sizes are smaller. I don't know why, but it's good. * Allocation is sometiemes a *lot* smaller. I believe that all the big numbers (I checked treejoin, gg, sorting) arise from one place, namely a function GHC.IO.Encoding.UTF8.utf8_decode, which is strict in two Buffers both of which have several arugments. Not w/w'ing both arguments (which is what we did before) has a big effect. So the big win in actually somewhat accidental, gained by removing the "unboxing strategy" code. * A couple of benchmarks allocate slightly more. This turns out to be due to reboxing (integrate). But the biggest increase is mandel2, and *that* turned out also to be a somewhat accidental loss of CSE, and pointed the way to doing better CSE: see Trac #7596. * Runtimes are never very reliable, but seem to improve very slightly. All in all, a good piece of work. Thank you Ilya!
* | Refactor and improve the promotion inferenceSimon Peyton Jones2013-01-251-2/+4
|/ | | | | | | | | | | | | | | | | | 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.
* Merge branch 'master' of http://darcs.haskell.org/ghcSimon Peyton Jones2012-12-231-8/+19
|\ | | | | | | | | | | Conflicts: compiler/basicTypes/MkId.lhs compiler/iface/IfaceSyn.lhs
| * Implement overlapping type family instances.Richard Eisenberg2012-12-211-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An ordered, overlapping type family instance is introduced by 'type instance where', followed by equations. See the new section in the user manual (7.7.2.2) for details. The canonical example is Boolean equality at the type level: type family Equals (a :: k) (b :: k) :: Bool type instance where Equals a a = True Equals a b = False A branched family instance, such as this one, checks its equations in order and applies only the first the matches. As explained in the note [Instance checking within groups] in FamInstEnv.lhs, we must be careful not to simplify, say, (Equals Int b) to False, because b might later unify with Int. This commit includes all of the commits on the overlapping-tyfams branch. SPJ requested that I combine all my commits over the past several months into one monolithic commit. The following GHC repos are affected: ghc, testsuite, utils/haddock, libraries/template-haskell, and libraries/dph. Here are some details for the interested: - The definition of CoAxiom has been moved from TyCon.lhs to a new file CoAxiom.lhs. I made this decision because of the number of definitions necessary to support BranchList. - BranchList is a GADT whose type tracks whether it is a singleton list or not-necessarily-a-singleton-list. The reason I introduced this type is to increase static checking of places where GHC code assumes that a FamInst or CoAxiom is indeed a singleton. This assumption takes place roughly 10 times throughout the code. I was worried that a future change to GHC would invalidate the assumption, and GHC might subtly fail to do the right thing. By explicitly labeling CoAxioms and FamInsts as being Unbranched (singleton) or Branched (not-necessarily-singleton), we make this assumption explicit and checkable. Furthermore, to enforce the accuracy of this label, the list of branches of a CoAxiom or FamInst is stored using a BranchList, whose constructors constrain its type index appropriately. I think that the decision to use BranchList is probably the most controversial decision I made from a code design point of view. Although I provide conversions to/from ordinary lists, it is more efficient to use the brList... functions provided in CoAxiom than always to convert. The use of these functions does not wander far from the core CoAxiom/FamInst logic. BranchLists are motivated and explained in the note [Branched axioms] in CoAxiom.lhs. - The CoAxiom type has changed significantly. You can see the new type in CoAxiom.lhs. It uses a CoAxBranch type to track branches of the CoAxiom. Correspondingly various functions producing and consuming CoAxioms had to change, including the binary layout of interface files. - To get branched axioms to work correctly, it is important to have a notion of type "apartness": two types are apart if they cannot unify, and no substitution of variables can ever get them to unify, even after type family simplification. (This is different than the normal failure to unify because of the type family bit.) This notion in encoded in tcApartTys, in Unify.lhs. Because apartness is finer-grained than unification, the tcUnifyTys now calls tcApartTys. - CoreLinting axioms has been updated, both to reflect the new form of CoAxiom and to enforce the apartness rules of branch application. The formalization of the new rules is in docs/core-spec/core-spec.pdf. - The FamInst type (in types/FamInstEnv.lhs) has changed significantly, paralleling the changes to CoAxiom. Of course, this forced minor changes in many files. - There are several new Notes in FamInstEnv.lhs, including one discussing confluent overlap and why we're not doing it. - lookupFamInstEnv, lookupFamInstEnvConflicts, and lookup_fam_inst_env' (the function that actually does the work) have all been more-or-less completely rewritten. There is a Note [lookup_fam_inst_env' implementation] describing the implementation. One of the changes that affects other files is to change the type of matches from a pair of (FamInst, [Type]) to a new datatype (which now includes the index of the matching branch). This seemed a better design. - The TySynInstD constructor in Template Haskell was updated to use the new datatype TySynEqn. I also bumped the TH version number, requiring changes to DPH cabal files. (That's why the DPH repo has an overlapping-tyfams branch.) - As SPJ requested, I refactored some of the code in HsDecls: * splitting up TyDecl into SynDecl and DataDecl, correspondingly changing HsTyDefn to HsDataDefn (with only one constructor) * splitting FamInstD into TyFamInstD and DataFamInstD and splitting FamInstDecl into DataFamInstDecl and TyFamInstDecl * making the ClsInstD take a ClsInstDecl, for parallelism with InstDecl's other constructors * changing constructor TyFamily into FamDecl * creating a FamilyDecl type that stores the details for a family declaration; this is useful because FamilyDecls can appear in classes but other decls cannot * restricting the associated types and associated type defaults for a * class to be the new, more restrictive types * splitting cid_fam_insts into cid_tyfam_insts and cid_datafam_insts, according to the new types * perhaps one or two more that I'm overlooking None of these changes has far-reaching implications. - The user manual, section 7.7.2.2, is updated to describe the new type family instances.
* | Make {-# UNPACK #-} work for type/data family invocationsSimon Peyton Jones2012-12-231-11/+9
|/ | | | | | | | | | | | | | | | | | | | | 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-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Replace all uses of ghcError with throwGhcException and purge ghcError.Erik de Castro Lopo2012-11-301-1/+1
|
* Make a start towards eta-rules and injective familiesSimon Peyton Jones2012-09-181-0/+12
| | | | | | | | | | | | | | | | | | | | * 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.
* Implement 'left' and 'right' coercionsSimon Peyton Jones2012-09-171-1/+13
| | | | | | | | | | | | | | | | | | | | | This patch finally adds 'left' and 'right' coercions back into GHC. Trac #7205 gives the details. The main change is to add a new constructor to Coercion: data Coercion = ... | NthCo Int Coercion -- OLD, still there | LRCo LeftOrRight Coercion -- NEW data LeftOrRight = CLeft | CRight Plus: * Similar change to TcCoercion * Use LRCo when decomposing AppTys * Coercion optimisation needs to handle left/right The rest is just knock-on effects.
* Move wORD_SIZE into platformConstantsIan Lynagh2012-09-161-2/+2
|
* Add "Unregisterised" as a field in the settings fileIan Lynagh2012-08-071-3/+2
| | | | | | To explicitly choose whether you want an unregisterised build you now need to use the "--enable-unregisterised"/"--disable-unregisterised" configure flags.
* Move -fno-warn-orphan flag into individual modulesIan Lynagh2012-07-151-0/+1
|
* Add silent superclass parameters (again)Simon Peyton Jones2012-06-271-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Silent superclass parameters solve the problem that the superclasses of a dicionary construction can easily turn out to be (wrongly) bottom. The problem and solution are described in Note [Silent superclass arguments] in TcInstDcls I first implemented this fix (with Dimitrios) in Dec 2010, but removed it again in Jun 2011 becuase we thought it wasn't necessary any more. (The reason we thought it wasn't necessary is that we'd stopped generating derived superclass constraints for *wanteds*. But we were wrong; that didn't solve the superclass-loop problem.) So we have to re-implement it. It's not hard. Main features: * The IdDetails for a DFunId says how many silent arguments it has * A DFunUnfolding describes which dictionary args are just parameters (DFunLamArg) and which are a function to apply to the parameters (DFunPolyArg). This adds the DFunArg type to CoreSyn * Consequential changes to IfaceSyn. (Binary hi file format changes slightly.) * TcInstDcls changes to generate the right dfuns * CoreSubst.exprIsConApp_maybe handles the new DFunUnfolding The thing taht is *not* done yet is to alter the vectoriser to pass the relevant extra argument when building a PA dictionary.
* Move and rename opt_HiVersionIan Lynagh2012-06-181-2/+2
| | | | It isn't really an option at all
* Make -firrefutable-tuples a dynamic flagIan Lynagh2012-06-181-1/+0
|
* Simplify the implementation of Implicit ParametersSimon Peyton Jones2012-06-131-18/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch re-implements implicit parameters via a class with a functional dependency: class IP (n::Symbol) a | n -> a where ip :: a This definition is in the library module GHC.IP. Notice how it use a type-literal, so we can have constraints like IP "x" Int Now all the functional dependency machinery works right to make implicit parameters behave as they should. Much special-case processing for implicit parameters can be removed entirely. One particularly nice thing is not having a dedicated "original-name cache" for implicit parameters (the nsNames field of NameCache). But many other cases disappear: * BasicTypes.IPName * IPTyCon constructor in Tycon.TyCon * CIPCan constructor in TcRnTypes.Ct * IPPred constructor in Types.PredTree Implicit parameters remain special in a few ways: * Special syntax. Eg the constraint (IP "x" Int) is parsed and printed as (?x::Int). And we still have local bindings for implicit parameters, and occurrences thereof. * A implicit-parameter binding (let ?x = True in e) amounts to a local instance declaration, which we have not had before. It just generates an implication contraint (easy), but when going under it we must purge any existing bindings for ?x in the inert set. See Note [Shadowing of Implicit Parameters] in TcSimplify * TcMType.sizePred classifies implicit parameter constraints as size-0, as before the change There are accompanying patches to libraries 'base' and 'haddock' All the work was done by Iavor Diatchki
* Pass DynFlags to the LogActionIan Lynagh2012-06-111-1/+1
| | | | | | | A side-effect is that we can no longer use the LogAction in defaultErrorHandler, as we don't have DynFlags at that point. But all that defaultErrorHandler did is to print Strings as SevFatal, so now it takes a 'FatalMessager' instead.
* Change how macros like ASSERT are definedIan Lynagh2012-06-051-0/+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.
* Make traceBinIFaceReading use log_actionIan Lynagh2012-05-281-1/+1
| | | | It was printing directly to stdout
* Allow cases with empty alterantivesSimon Peyton Jones2012-05-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | This patch allows, for the first time, case expressions with an empty list of alternatives. Max suggested the idea, and Trac #6067 showed that it is really quite important. So I've implemented the idea, fixing #6067. Main changes * See Note [Empty case alternatives] in CoreSyn * Various foldr1's become foldrs * IfaceCase does not record the type of the alternatives. I added IfaceECase for empty-alternative cases. * Core Lint does not complain about empty cases * MkCore.castBottomExpr constructs an empty-alternative case expression (case e of ty {}) * CoreToStg converts '(case e of {})' to just 'e'
* Merge remote-tracking branch 'origin/master' into type-natsIavor S. Diatchki2012-03-131-87/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: compiler/coreSyn/CoreLint.lhs compiler/deSugar/DsBinds.lhs compiler/hsSyn/HsTypes.lhs compiler/iface/IfaceType.lhs compiler/rename/RnHsSyn.lhs compiler/rename/RnTypes.lhs compiler/stgSyn/StgLint.lhs compiler/typecheck/TcHsType.lhs compiler/utils/ListSetOps.lhs
| * Simplified serialization of IfaceTyCon, againMax Bolingbroke2012-02-221-85/+8
| | | | | | | | | | | | Jose's patch implementing kind-polymorphic core (09015be8d580bc33f5f1960c8e31d00ba7a459a1) reverted many of the simplifying changes to interface file TyCon serialization I had made in a previous patch (5d7173f9ab8405511f75765e0541a04796d9bd07). Based on the diff I think this was an unintended consequence of how Jose did the merge rather than a real change he intended to make. In fact, as a result of kind-polymorphic core we don't need to treat the Any TyCon specially any longer so my old simplifying changes can be made even simpler: IfaceTyCon is now just a newtype on IfaceExtName.
| * Remove support for CTYPE pragmas on type synonymsIan Lynagh2012-02-221-4/+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/+8
| | | | | | | | | | | | | | For now, the syntax is type {-# CTYPE "some C type" #-} Foo = ... newtype {-# CTYPE "some C type" #-} Foo = ... data {-# CTYPE "some C type" #-} Foo = ...
* | Add support for type-level "strings".Iavor S. Diatchki2012-01-241-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | These are types that look like "this" and "that". They are of kind `Symbol`, defined in module `GHC.TypeLits`. For each type-level symbol `X`, we have a singleton type, `TSymbol X`. The value of the singleton type can be named with the overloaded constant `tSymbol`. Here is an example: tSymbol :: TSymbol "Hello"
* | Merge remote-tracking branch 'origin/master' into type-natsIavor S. Diatchki2012-01-241-12/+1
|\ \ | |/ | | | | | | Conflicts: compiler/typecheck/TcEvidence.lhs
| * Remove getDOpts; use getDynFlags insteadIan Lynagh2012-01-191-1/+1
| |
| * Switch to using the time package, rather than old-timeIan Lynagh2012-01-141-11/+0
| |
* | Mainly, rename LiteralTy to LitTySimon Peyton Jones2012-01-131-2/+2
| |
* | Merge remote-tracking branch 'origin/master' into type-natsIavor S. Diatchki2012-01-071-16/+29
|\ \ | |/
| * Major refactoring of CoAxiomsSimon Peyton Jones2012-01-031-16/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
View Lorry Controller Status