- 11 Jun, 2008 2 commits
-
-
Ian Lynagh authored
This disappeared when we stopped being "fptools" and became just "ghc"
-
Ian Lynagh authored
-
- 10 Jun, 2008 4 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 06 Jun, 2008 16 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
One of the conditions we were checking was t2 `eqPatLType` t2 rather than t1 `eqPatLType` t2
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
When we deal with a family-instance declaration (TcTyClsDecls.tcFamInstDecl) we must check the TyCon for validity; for example, that a newtype has exactly one field. That is done all-at-once for normal declarations, and had been forgotten altogether for families. I also refactored the interface to tcFamInstDecl1 slightly. A slightly separate matter: if there's an error in family instances (e.g. overlap) we get a confusing error message cascade if we attempt to deal with 'deriving' clauses too; this patch bales out earlier in that case. Another slightly separate matter: standalone deriving for family instances can legitimately have more specific types, just like normal data decls. For example data instance F [a] = ... deriving instance (Eq a, Eq b) => Eq (F [(a,b)]) So tcLookupFamInstExact can a bit more forgiving than it was.
-
- 05 Jun, 2008 5 commits
-
-
simonpj@microsoft.com authored
Sorry -- my 'validate' didn't work right and I missed a trick. This patch must accompany * Fix Trac #2045: use big-tuple machiney for implication constraints
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
Occasionally people write very large recursive groups of definitions. In general we desugar these to a single definition that binds tuple, plus lots of tuple selectors. But that code has quadratic size, which can be bad. This patch adds a new case to the desugaring of bindings, for the situation where there are lots of polymorphic variables, but no dictionaries. (Dictionaries force us into the general case.) See Note [Abstracting over tyvars only]. The extra behaviour can be disabled with the (static) flag -fno-ds-multi-tyvar in case we want to experiment with switching it on or off. There is essentially-zero effect on the nofib suite though. I was provoked into doing this by Trac #1136. In fact I'm not sure it's the real cause of the problem there, but it's a good idea anyway.
-
simonpj@microsoft.com authored
This patch adds to Core the ability to say let a = Int in <body> where 'a' is a type variable. That is: a type-let. See Note [Type let] in CoreSyn. * The binding is always non-recursive * The simplifier immediately eliminates it by substitution So in effect a type-let is just a delayed substitution. This is convenient in a couple of places in the desugarer, one existing (see the call to CoreTyn.mkTyBind in DsUtils), and one that's in the next upcoming patch. The first use in the desugarer was previously encoded as (/\a. <body>) Int rather that eagerly substituting, but that was horrid because Core Lint had do "know" that a=Int inside <body> else it would bleat. Expressing it directly as a 'let' seems much nicer.
-
- 04 Jun, 2008 9 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
We have not supported "result type signatures" for some time, but using one in the wrong way caused a crash. This patch tidies it up.
-
simonpj@microsoft.com authored
This affects only the debug print TcRnDriver.pprTcGblEnv, and eliminates test-suite wobbling (affected me for tc168, tc231)
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
chak@cse.unsw.edu.au. authored
-
chak@cse.unsw.edu.au. authored
-
- 03 Jun, 2008 1 commit
-
-
simonpj@microsoft.com authored
-
- 30 May, 2008 2 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
- 03 Jun, 2008 1 commit
-
-
Simon Marlow authored
-