add support for <{..}> and ~~> syntax as well as typing for Kappa-calculus
merge upstream
Make TH capable of quoting GADT declarations (Trac #5217) Template Haskell doesn't support GADTs directly but we can use equality constraints to do the job. Here's an example of the dump from splicing such a declaration: [d| data T a b where T1 :: Int -> T Int Char T2 :: a -> T a a T3 :: a -> T [a] a T4 :: a -> b -> T b [a] |] ======> T5217.hs:(6,3)-(9,53) data T a[aQW] b[aQX] = (b[aQX] ~ Char, a[aQW] ~ Int) => T1 Int | b[aQX] ~ a[aQW] => T2 a[aQW] | a[aQW] ~ [b[aQX]] => T3 b[aQX] | forall a[aQY]. b[aQX] ~ [a[aQY]] => T4 a[aQY] a[aQW]
adapt HetMet extensions to new GHC coercion representation
merge GHC HEAD
TcHsType: set the kind for tyvars that occur in explicit code types
Merge branch 'master' of darcs.haskell.org/ghc into ghc-generics Resolved conflicts: compiler/typecheck/TcTyClsDecls.lhs
Remove HsNumTy and TypePati. They belonged to the old generic deriving mechanism, so they can go. Adapted a lot of code as a consequence.
This BIG PATCH contains most of the work for the New Coercion Representation 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
Initial checkin of HetMet / -XModalTypes modifications
Major refactoring of the type inference engine This patch embodies many, many changes to the contraint solver, which make it simpler, more robust, and more beautiful. But it has taken me ages to get right. The forcing issue was some obscure programs involving recursive dictionaries, but these eventually led to a massive refactoring sweep. Main changes are: * No more "frozen errors" in the monad. Instead "insoluble constraints" are now part of the WantedConstraints type. * The WantedConstraint type is a product of bags, instead of (as before) a bag of sums. This eliminates a good deal of tagging and untagging. * This same WantedConstraints data type is used - As the way that constraints are gathered - As a field of an implication constraint - As both argument and result of solveWanted - As the argument to reportUnsolved * We do not generate any evidence for Derived constraints. They are purely there to allow "impovement" by unifying unification variables. * In consequence, nothing is ever *rewritten* by a Derived constraint. This removes, by construction, all the horrible potential recursive-dictionary loops that were making us tear our hair out. No more isGoodRecEv search either. Hurrah! * We add the superclass Derived constraints during canonicalisation, after checking for duplicates. So fewer superclass constraints are generated than before. * Skolem tc-tyvars no longer carry SkolemInfo. Instead, the SkolemInfo lives in the GivenLoc of the Implication, where it can be tidied, zonked, and substituted nicely. This alone is a major improvement. * Tidying is improved, so that we tend to get t1, t2, t3, rather than t1, t11, t111, etc Moreover, unification variables are always printed with a digit (thus a0, a1, etc), so that plain 'a' is available for a skolem arising from a type signature etc. In this way, (a) We quietly say which variables are unification variables, for those who know and care (b) Types tend to get printed as the user expects. If he writes f :: a -> a f = ...blah... then types involving 'a' get printed with 'a', rather than some tidied variant. * There are significant improvements in error messages, notably in the "Cannot deduce X from Y" messages.
Fix recursive superclasses (again). Fixes Trac #4809. This patch finally deals with the super-delicate question of superclases in possibly-recursive dictionaries. The key idea is the DFun Superclass Invariant (see TcInstDcls): In the body of a DFun, every superclass argument to the returned dictionary is either * one of the arguments of the DFun, or * constant, bound at top level To establish the invariant, we add new "silent" superclass argument(s) to each dfun, so that the dfun does not do superclass selection internally. There's a bit of hoo-ha to make sure that we don't print those silent arguments in error messages; a knock on effect was a change in interface-file format. A second change is that instead of the complex and fragile "self dictionary binding" in TcInstDcls and TcClassDcl, using the same mechanism for existential pattern bindings. See Note [Subtle interaction of recursion and overlap] in TcInstDcls and Note [Binding when looking up instances] in InstEnv. Main notes are here: * Note [Silent Superclass Arguments] in TcInstDcls, including the DFun Superclass Invariant Main code changes are: * The code for MkId.mkDictFunId and mkDictFunTy * DFunUnfoldings get a little more complicated; their arguments are a new type DFunArg (in CoreSyn) * No "self" argument in tcInstanceMethod * No special tcSimplifySuperClasss * No "dependents" argument to EvDFunApp IMPORTANT It turns out that it's quite tricky to generate the right DFunUnfolding for a specialised dfun, when you use SPECIALISE INSTANCE. For now I've just commented it out (in DsBinds) but that'll lose some optimisation, and I need to get back to this.
Implement TH reification of instances (Trac #1835) Accompanying patch for template-haskell package is reqd
Super-monster patch implementing the new typechecker -- at last 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.
Add HsCoreTy to HsType The main thing here is to allow us to provide type signatures for 'deriving' bindings without pain.
Keep track of explicit kinding in HsTyVarBndr; plus fix Trac #3845 To print HsTypes correctly we should remember whether the Kind on a HsTyVarBndr came from type inference, or was put there by the user. See Note [Printing KindedTyVars] in HsTypes. So instead of changing a UserTyVar to a KindedTyVar during kind checking, we simply add a PostTcKind to the UserTyVar. The change was provoked by Trac #3830, although other changes mean that #3830 gets a diferent and better error message now. So this patch is simply doing the Right Thing for the future. This patch also fixes Trac #3845, which was caused by a *type splice* not remembering the free *term variables* mentioned in it. Result was that we build a 'let' when it should have been 'letrec'. Hence a new FreeVars field in HsSpliceTy. While I was at it, I got rid of HsSpliceTyOut and use a PostTcKind on HsSpliceTy instead, just like on the UserTyVar.
Several TH/quasiquote changes a) Added quasi-quote forms for declarations types e.g. f :: [$qq| ... |] b) Allow Template Haskell pattern quotes (but not splices) e.g. f x = [p| Int -> $x |] c) Improve pretty-printing for HsPat to remove superfluous parens. (This isn't TH related really, but it affects some of the same code.) A consequence of (a) is that when gathering and grouping declarations in RnSource.findSplice, we must expand quasiquotes as we do so. Otherwise it's all fairly straightforward. I did a little bit of refactoring in TcSplice. User-manual changes still to come.
Update layout of error message slightly
Fix Trac #3540: malformed types Tidy up the way that predicates are handled inside types
Three improvements to Template Haskell (fixes #3467) This patch implements three significant improvements to Template Haskell. Declaration-level splices with no "$" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This change simply allows you to omit the "$(...)" wrapper for declaration-level TH splices. An expression all by itself is not legal, so we now treat it as a TH splice. Thus you can now say data T = T1 | T2 deriveMyStuff ''T where deriveMyStuff :: Name -> Q [Dec] This makes a much nicer interface for clients of libraries that use TH: no scary $(deriveMyStuff ''T). Nested top-level splices ~~~~~~~~~~~~~~~~~~~~~~~~ Previously TH would reject this, saying that splices cannot be nested: f x = $(g $(h 'x)) But there is no reason for this not to work. First $(h 'x) is run, yielding code <blah> that is spliced instead of the $(h 'x). Then (g <blah>) is typechecked and run, yielding code that replaces the $(g ...) splice. So this simply lifts the restriction. Fix Trac #3467: non-top-level type splices ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It appears that when I added the ability to splice types in TH programs, I failed to pay attention to non-top-level splices -- that is, splices inside quotatation brackets. This patch fixes the problem. I had to modify HsType, so there's a knock-on change to Haddock. Its seems that a lot of lines of code has changed, but almost all the new lines are comments! General tidying up ~~~~~~~~~~~~~~~~~~ As a result of thinking all this out I re-jigged the data type ThStage, which had far too many values before. And I wrote a nice state transition diagram to make it all precise; see Note [Template Haskell state diagram] in TcSplice Lots more refactoring in TcSplice, resulting in significantly less code. (A few more lines, but actually less code -- the rest is comments.) I think the result is significantly cleaner.