| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two significant changes to the representation of types
1. Change the representation of type synonyms
Up to now, type synonym applications have been held in
*both* expanded *and* un-expanded form. Unfortunately, this
has exponential (!) behaviour when type synonyms are deeply
nested. E.g.
type P a b = (a,b)
f :: P a (P b (P c (P d e)))
This showed up in a program of Joel Reymont, now immortalised
as typecheck/should_compile/syn-perf.hs
So now synonyms are held as ordinary TyConApps, and expanded
only on demand.
SynNote has disappeared altogether, so the only remaining TyNote
is a FTVNote. I'm not sure if it's even useful.
2. Eta-reduce newtypes
See the Note [Newtype eta] in TyCon.lhs
If we have
newtype T a b = MkT (S a b)
then, in Core land, we would like S = T, even though the application
of T is then not saturated. This commit eta-reduces T's RHS, and
keeps that inside the TyCon (in nt_etad_rhs). Result is that
coreEqType can be simpler, and has less need of expanding newtypes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add record syntax for GADTs
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Atrijus Tang wanted to add record syntax for GADTs and existential
types, so he and I worked on it a bit at ICFP. This commit is the
result. Now you can say
data T a where
T1 { x :: a } :: T [a]
T2 { x :: a, y :: Int } :: T [a]
forall b. Show b =>
T3 { naughty :: b, ok :: Int } :: T Int
T4 :: Eq a => a -> b -> T (a,b)
Here the constructors are declared using record syntax.
Still to come after this commit:
- User manual documentation
- More regression tests
- Some missing cases in the parser (e.g. T3 won't parse)
Autrijus is going to do these.
Here's a quick summary of the rules. (Atrijus is going to write
proper documentation shortly.)
Defnition: a 'vanilla' constructor has a type of the form
forall a1..an. t1 -> ... -> tm -> T a1 ... an
No existentials, no context, nothing. A constructor declared with
Haskell-98 syntax is vanilla by construction. A constructor declared
with GADT-style syntax is vanilla iff its type looks like the above.
(In the latter case, the order of the type variables does not matter.)
* You can mix record syntax and non-record syntax in a single decl
* All constructors that share a common field 'x' must have the
same result type (T [a] in the example).
* You can use field names without restriction in record construction
and record pattern matching.
* Record *update* only works for data types that only have 'vanilla'
constructors.
* Consider the field 'naughty', which uses a type variable that does
not appear in the result type ('b' in the example). You can use the
field 'naughty' in pattern matching and construction, but NO
SELECTOR function is generated for 'naughty'. [An attempt to use
'naughty' as a selector function will elicit a helpful error
message.]
* Data types declared in GADT syntax cannot have a context. So this
is illegal:
data (Monad m) => T a where
....
* Constructors in GADT syntax can have a context (t.g. T3, T4 above)
and that context is stored in the constructor and made available
when the constructor is pattern-matched on. WARNING: not competely
implemented yet, but that's the plan.
Implementation notes
~~~~~~~~~~~~~~~~~~~~
- Data constructors (even vanilla ones) no longer share the type
variables of their parent type constructor.
- HsDecls.ConDecl has changed quite a bit
- TyCons don't record the field labels and type any more (doesn't
make sense for existential fields)
- GlobalIdDetails records which selectors are 'naughty', and hence
don't have real code.
|
| |
|
|
| |
Comments
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tune up the reporting of unused imports
Merge to STABLE
(I think the earlier change made it across)
(PS: the commit also does some trimming of
redundant imports. If they don't merge, just
discard them.)
My earlier fixes to the reporting of unused imports still missed
some obscure cases, some of which are now fixed by this commit.
I had to make the import-provenance data type yet richer, but in
fact it has more sharing now, so it may be cheaper on space.
There's still one infelicity. Consider
import M( x )
imoprt N( x )
where the same underlying 'x' is involved in both cases. Currently we
don't report a redundant import, because dropping either import would
change the qualified names in scope (M.x, N.x). But if the qualified
names aren't used, the import is indeed redundant. Sadly we don't know
that, because we only know what Names are used. Left for the future!
There's a comment in RnNames.warnDuplicateImports
This commit also trims quite a few redundant imports disovered
by the new setup.
|
| |
|
|
|
|
|
|
|
|
|
| |
Newtype representation
Merge to STABLE
This commit fixes a long-standing bug (simple clerical error) in mkNewTyConRep,
which for some reason had gone un-discovered for years.
tc183 tests it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This big commit does several things at once (aeroplane hacking)
which change the format of interface files.
So you'll need to recompile your libraries!
1. The "stupid theta" of a newtype declaration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Retain the "stupid theta" in a newtype declaration.
For some reason this was being discarded, and putting it
back in meant changing TyCon and IfaceSyn slightly.
2. Overlap flags travel with the instance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Arrange that the ability to support overlap and incoherence
is a property of the *instance declaration* rather than the
module that imports the instance decl. This allows a library
writer to define overlapping instance decls without the
library client having to know.
The implementation is that in an Instance we store the
overlap flag, and preseve that across interface files
3. Nuke the "instnce pool" and "rule pool"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A major tidy-up and simplification of the way that instances
and rules are sucked in from interface files. Up till now
an instance decl has been held in a "pool" until its "gates"
(a set of Names) are in play, when the instance is typechecked
and added to the InstEnv in the ExternalPackageState.
This is complicated and error-prone; it's easy to suck in
too few (and miss an instance) or too many (and thereby be
forced to suck in its type constructors, etc).
Now, as we load an instance from an interface files, we
put it straight in the InstEnv... but the Instance we put in
the InstEnv has some Names (the "rough-match" names) that
can be used on lookup to say "this Instance can't match".
The detailed dfun is only read lazily, and the rough-match
thing meansn it is'nt poked on until it has a chance of
being needed.
This simply continues the successful idea for Ids, whereby
they are loaded straightaway into the TypeEnv, but their
TyThing is a lazy thunk, not poked on until the thing is looked
up.
Just the same idea applies to Rules.
On the way, I made CoreRule and Instance into full-blown records
with lots of info, with the same kind of key status as TyCon or
DataCon or Class. And got rid of IdCoreRule altogether.
It's all much more solid and uniform, but it meant touching
a *lot* of modules.
4. Allow instance decls in hs-boot files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allowing instance decls in hs-boot files is jolly useful, becuase
in a big mutually-recursive bunch of data types, you want to give
the instances with the data type declarations. To achieve this
* The hs-boot file makes a provisional name for the dict-fun, something
like $fx9.
* When checking the "mother module", we check that the instance
declarations line up (by type) and generate bindings for the
boot dfuns, such as
$fx9 = $f2
where $f2 is the dfun generated by the mother module
* In doing this I decided that it's cleaner to have DFunIds get their
final External Name at birth. To do that they need a stable OccName,
so I have an integer-valued dfun-name-supply in the TcM monad.
That keeps it simple.
This feature is hardly tested yet.
5. Tidy up tidying, and Iface file generation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
main/TidyPgm now has two entry points:
simpleTidyPgm is for hi-boot files, when typechecking only
(not yet implemented), and potentially when compiling without -O.
It ignores the bindings, and generates a nice small TypeEnv.
optTidyPgm is the normal case: compiling with -O. It generates a
TypeEnv rich in IdInfo
MkIface.mkIface now only generates a ModIface. A separate
procedure, MkIface.writeIfaceFile, writes the file out to disk.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------
Add Generalised Algebraic Data Types
------------------------------------
This rather big commit adds support for GADTs. For example,
data Term a where
Lit :: Int -> Term Int
App :: Term (a->b) -> Term a -> Term b
If :: Term Bool -> Term a -> Term a
..etc..
eval :: Term a -> a
eval (Lit i) = i
eval (App a b) = eval a (eval b)
eval (If p q r) | eval p = eval q
| otherwise = eval r
Lots and lots of of related changes throughout the compiler to make
this fit nicely.
One important change, only loosely related to GADTs, is that skolem
constants in the typechecker are genuinely immutable and constant, so
we often get better error messages from the type checker. See
TcType.TcTyVarDetails.
There's a new module types/Unify.lhs, which has purely-functional
unification and matching for Type. This is used both in the typechecker
(for type refinement of GADTs) and in Core Lint (also for type refinement).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-----------------------------------------------
Record whether data constructors are declared infix
-----------------------------------------------
This allows us to generate the InfixC form in Template Hasekll.
And for 'deriving' Read and Show, we now read and parse the infix
form iff the constructor was declared infix, rather than just if
it does not have the default fixity (as before).
IfaceSyn changes slightly, so that IfaceConDecl can record their
fixity, so there are trivial changes scattered about, and
you'll need to recompile everything.
In TysWiredIn I took the opportunity to simplify pcDataCon slightly,
by eliminating the unused Theta argument.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------
More newtype clearing up
------------------------
* Change the representation of TyCons so that it accurately reflects
* data (0 or more constrs)
* newtype (1 constr)
* abstract (unknown)
Replaces DataConDetails and AlgTyConFlavour with AlgTyConRhs
* Add IfaceSyn.IfaceConDecls, a kind of stripped-down analogue
of AlgTyConRhs
* Move NewOrData from BasicTypes to HsDecl (it's now an HsSyn thing)
* Arrange that Type.newTypeRep and splitRecNewType_maybe unwrap just
one layer of new-type-ness, leaving the caller to recurse.
This still leaves typeRep and repType in Type.lhs; these functions
are still vaguely disturbing and probably should get some attention.
Lots of knock-on changes. Fixes bug in ds054.
|
| |
|
|
| |
Comments
|
|
|
Oops; forgot to add this entire directory!
|
