| 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.
|
| |
|
|
|
| |
-fignore-breakpoints can be used to ignore breakpoints.
|
| | |
|
| |
|
|
|
|
|
|
| |
I've removed -fno-code from Main to make it work
equally well with --make and -c.
I've also allowed it not to write hi files unless
-fwrite-iface is given.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
I've removed -fno-code from Main to make it work
equally well with --make and -c.
I've also allowed it not to write hi files unless
-fwrite-iface is given.
|
| | |
|
| |
|
|
|
|
| |
Contributed by Duncan Coutts, with changes to merge into the HEAD.
This isn't the full deal, ghc-pkg still modifies files only, but it's
enough to help the Gentoo folk along.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the lexer to parse OPTIONS, LANGUAGE and INCLUDE pragmas.
This gives us greater flexibility and far better error
messages. However, I had to make a few quirks:
* The token parser is written manually since Happy doesn't
like lexer errors (we need to extract options before the
buffer is passed through 'cpp'). Still better than
manually parsing a String, though.
* The StringBuffer API has been extended so files can be
read in blocks.
I also made a new field in ModSummary called ms_hspp_opts
which stores the updated DynFlags. Oh, and I took the liberty
of moving 'getImports' into HeaderInfo together with
'getOptions'.
|
| | |
|
| |
|
|
|
|
| |
I'm not sure what really happens here but this is how it's
done in the old HscMain code and it appears to work.
|
| |
|
|
| |
This seems to be required now that we're stealing more registers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MkIface.writeIfaceFile doesn't check GhcMode anymore. All it does
is what the name say: write an interface to disk.
I've refactored HscMain so the logic is easier to manage. That means
we can avoid running the simplifier when typechecking (: And best of
all, HscMain doesn't use GhcMode at all, anymore!
The new HscMain intro looks like this:
It's the task of the compilation proper to compile Haskell, hs-boot and
core files to either byte-code, hard-code (C, asm, Java, ect) or to
nothing at all (the module is still parsed and type-checked. This
feature is mostly used by IDE's and the likes).
Compilation can happen in either 'one-shot', 'batch', 'nothing',
or 'interactive' mode. 'One-shot' mode targets hard-code, 'batch' mode
targets hard-code, 'nothing' mode targets nothing and 'interactive' mode
targets byte-code.
The modes are kept separate because of their different types and meanings.
In 'one-shot' mode, we're only compiling a single file and can therefore
discard the new ModIface and ModDetails. This is also the reason it only
targets hard-code; compiling to byte-code or nothing doesn't make sense
when we discard the result.
'Batch' mode is like 'one-shot' except that we keep the resulting ModIface
and ModDetails. 'Batch' mode doesn't target byte-code since that require
us to return the newly compiled byte-code.
'Nothing' mode has exactly the same type as 'batch' mode but they're still
kept separate. This is because compiling to nothing is fairly special: We
don't output any interface files, we don't run the simplifier and we don't
generate any code.
'Interactive' mode is similar to 'batch' mode except that we return the
compiled byte-code together with the ModIface and ModDetails.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
None of the new code is in use yet.
The current Haskell compiler (HscMain.hscMain) isn't as typed
and as hack-free as we'd like. Here's a list of the things it
does wrong:
* In one shot mode, it returns the new interface as _|_,
when recompilation isn't required. It's then up to the
users of hscMain to keep their hands off the result.
* (Maybe ModIface) is passed around when it's known that it's
a Just. Hey, we got a type-system, let's use it.
* In one shot mode, the backend is returning _|_ for the
new interface. This is done to prevent space leaks since
we know that the result of a one shot compilation is never
used. Again, it's up to the users of hscMain to keep their
hands off the result.
* It is allowed to compile a hs-boot file to bytecode even
though that doesn't make sense (it always returns
Nothing::Maybe CompiledByteCode).
* Logic and grunt work is completely mixed. The frontend
and backend keeps checking what kind of input they're handling.
This makes it very hard to get an idea of what the functions
actually do.
* Extra work is performed when using a null code generator.
The new code refactors out the frontends (Haskell, Core), the
backends (Haskell, boot) and the code generators (one-shot, make,
nothing, interactive) and allows them to be combined in typesafe ways.
A one-shot compilation doesn't return new interfaces at all so we
don't need the _|_ space-leak hack. In 'make' mode (when not
targeting bytecode) the result doesn't contain
Nothing::Maybe CompiledByteCode. In interactive mode, the result
is always a CompiledByteCode. The code gens are completely separate
so compiling to Nothing doesn't perform any extra work.
DriverPipeline needs a bit of work before it can use the new
API.
|
| |
|
|
|
|
|
|
| |
This turned out to be a lot easier than I thought. Just moving a few
bits of -split-objs support from the build system into the compiler
was enough. The only thing that Cabal needs to do in order to support
-split-objs now is to pass the names of the split objects rather than
the monolithic ones to 'ar'.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Eliminate things like "warning: call-clobbered register used as global
register variable", which is an non-suppressible warning from gcc.
|
| | |
|
| |
|
|
|
|
| |
This restructoring makes the renamed export and import lists
available in IDE mode.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Now, the threaded RTS also includes SMP support. The -smp flag is a
synonym for -threaded. The performance implications of this are small
to negligible, and it results in a code cleanup and reduces the number
of combinations we have to test.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had to bite the bullet here and add an extra word to every thunk,
to enable running ordinary libraries on SMP. Otherwise, we would have
needed to ship an extra set of libraries with GHC 6.6 in addition to
the two sets we already ship (normal + profiled), and all Cabal
packages would have to be compiled for SMP too. We decided it best
just to take the hit now, making SMP easily accessible to everyone in
GHC 6.6.
Incedentally, although this increases allocation by around 12% on
average, the performance hit is around 5%, and much less if your inner
loop doesn't use any laziness.
|
| | |
|
| |
|
|
|
|
|
|
| |
This patch adds completion support to GHCi when readline is being
used. Completion of identifiers (in scope only, but including
qualified identifiers) in expressions is provided. Also, completion
of commands (:cmd), and special completion for certain commands
(eg. module names for the :module command) are also provided.
|
| |
|
|
|
|
|
|
|
|
| |
This commit adds bang-patterns,
enabled by -fglasgow-exts or -fbang-patterns
diabled by -fno-bang-patterns
The idea is described here
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/BangPatterns
|
| |
|
|
| |
Also extend the parser.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This very large commit adds impredicativity to GHC, plus
numerous other small things.
*** WARNING: I have compiled all the libraries, and
*** a stage-2 compiler, and everything seems
*** fine. But don't grab this patch if you
*** can't tolerate a hiccup if something is
*** broken.
The big picture is this:
a) GHC handles impredicative polymorphism, as described in the
"Boxy types: type inference for higher-rank types and
impredicativity" paper
b) GHC handles GADTs in the new simplified (and very sligtly less
epxrssive) way described in the
"Simple unification-based type inference for GADTs" paper
But there are lots of smaller changes, and since it was pre-Darcs
they are not individually recorded.
Some things to watch out for:
c) The story on lexically-scoped type variables has changed, as per
my email. I append the story below for completeness, but I
am still not happy with it, and it may change again. In particular,
the new story does not allow a pattern-bound scoped type variable
to be wobbly, so (\(x::[a]) -> ...) is usually rejected. This is
more restrictive than before, and we might loosen up again.
d) A consequence of adding impredicativity is that GHC is a bit less
gung ho about converting automatically between
(ty1 -> forall a. ty2) and (forall a. ty1 -> ty2)
In particular, you may need to eta-expand some functions to make
typechecking work again.
Furthermore, functions are now invariant in their argument types,
rather than being contravariant. Again, the main consequence is
that you may occasionally need to eta-expand function arguments when
using higher-rank polymorphism.
Please test, and let me know of any hiccups
Scoped type variables in GHC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
January 2006
0) Terminology.
A *pattern binding* is of the form
pat = rhs
A *function binding* is of the form
f pat1 .. patn = rhs
A binding of the formm
var = rhs
is treated as a (degenerate) *function binding*.
A *declaration type signature* is a separate type signature for a
let-bound or where-bound variable:
f :: Int -> Int
A *pattern type signature* is a signature in a pattern:
\(x::a) -> x
f (x::a) = x
A *result type signature* is a signature on the result of a
function definition:
f :: forall a. [a] -> a
head (x:xs) :: a = x
The form
x :: a = rhs
is treated as a (degnerate) function binding with a result
type signature, not as a pattern binding.
1) The main invariants:
A) A lexically-scoped type variable always names a (rigid)
type variable (not an arbitrary type). THIS IS A CHANGE.
Previously, a scoped type variable named an arbitrary *type*.
B) A type signature always describes a rigid type (since
its free (scoped) type variables name rigid type variables).
This is also a change, a consequence of (A).
C) Distinct lexically-scoped type variables name distinct
rigid type variables. This choice is open;
2) Scoping
2(a) If a declaration type signature has an explicit forall, those type
variables are brought into scope in the right hand side of the
corresponding binding (plus, for function bindings, the patterns on
the LHS).
f :: forall a. a -> [a]
f (x::a) = [x :: a, x]
Both occurences of 'a' in the second line are bound by
the 'forall a' in the first line
A declaration type signature *without* an explicit top-level forall
is implicitly quantified over all the type variables that are
mentioned in the type but not already in scope. GHC's current
rule is that this implicit quantification does *not* bring into scope
any new scoped type variables.
f :: a -> a
f x = ...('a' is not in scope here)...
This gives compatibility with Haskell 98
2(b) A pattern type signature implicitly brings into scope any type
variables mentioned in the type that are not already into scope.
These are called *pattern-bound type variables*.
g :: a -> a -> [a]
g (x::a) (y::a) = [y :: a, x]
The pattern type signature (x::a) brings 'a' into scope.
The 'a' in the pattern (y::a) is bound, as is the occurrence on
the RHS.
A pattern type siganture is the only way you can bring existentials
into scope.
data T where
MkT :: forall a. a -> (a->Int) -> T
f x = case x of
MkT (x::a) f -> f (x::a)
2a) QUESTION
class C a where
op :: forall b. b->a->a
instance C (T p q) where
op = <rhs>
Clearly p,q are in scope in <rhs>, but is 'b'? Not at the moment.
Nor can you add a type signature for op in the instance decl.
You'd have to say this:
instance C (T p q) where
op = let op' :: forall b. ...
op' = <rhs>
in op'
3) A pattern-bound type variable is allowed only if the pattern's
expected type is rigid. Otherwise we don't know exactly *which*
skolem the scoped type variable should be bound to, and that means
we can't do GADT refinement. This is invariant (A), and it is a
big change from the current situation.
f (x::a) = x -- NO; pattern type is wobbly
g1 :: b -> b
g1 (x::b) = x -- YES, because the pattern type is rigid
g2 :: b -> b
g2 (x::c) = x -- YES, same reason
h :: forall b. b -> b
h (x::b) = x -- YES, but the inner b is bound
k :: forall b. b -> b
k (x::c) = x -- NO, it can't be both b and c
3a) You cannot give different names for the same type variable in the same scope
(Invariant (C)):
f1 :: p -> p -> p -- NO; because 'a' and 'b' would be
f1 (x::a) (y::b) = (x::a) -- bound to the same type variable
f2 :: p -> p -> p -- OK; 'a' is bound to the type variable
f2 (x::a) (y::a) = (x::a) -- over which f2 is quantified
-- NB: 'p' is not lexically scoped
f3 :: forall p. p -> p -> p -- NO: 'p' is now scoped, and is bound to
f3 (x::a) (y::a) = (x::a) -- to the same type varialble as 'a'
f4 :: forall p. p -> p -> p -- OK: 'p' is now scoped, and its occurences
f4 (x::p) (y::p) = (x::p) -- in the patterns are bound by the forall
3b) You can give a different name to the same type variable in different
disjoint scopes, just as you can (if you want) give diferent names to
the same value parameter
g :: a -> Bool -> Maybe a
g (x::p) True = Just x :: Maybe p
g (y::q) False = Nothing :: Maybe q
3c) Scoped type variables respect alpha renaming. For example,
function f2 from (3a) above could also be written:
f2' :: p -> p -> p
f2' (x::b) (y::b) = x::b
where the scoped type variable is called 'b' instead of 'a'.
4) Result type signatures obey the same rules as pattern types signatures.
In particular, they can bind a type variable only if the result type is rigid
f x :: a = x -- NO
g :: b -> b
g x :: b = x -- YES; binds b in rhs
5) A *pattern type signature* in a *pattern binding* cannot bind a
scoped type variable
(x::a, y) = ... -- Legal only if 'a' is already in scope
Reason: in type checking, the "expected type" of the LHS pattern is
always wobbly, so we can't bind a rigid type variable. (The exception
would be for an existential type variable, but existentials are not
allowed in pattern bindings either.)
Even this is illegal
f :: forall a. a -> a
f x = let ((y::b)::a, z) = ...
in
Here it looks as if 'b' might get a rigid binding; but you can't bind
it to the same skolem as a.
6) Explicitly-forall'd type variables in the *declaration type signature(s)*
for a *pattern binding* do not scope AT ALL.
x :: forall a. a->a -- NO; the forall a does
Just (x::a->a) = Just id -- not scope at all
y :: forall a. a->a
Just y = Just (id :: a->a) -- NO; same reason
THIS IS A CHANGE, but one I bet that very few people will notice.
Here's why:
strange :: forall b. (b->b,b->b)
strange = (id,id)
x1 :: forall a. a->a
y1 :: forall b. b->b
(x1,y1) = strange
This is legal Haskell 98 (modulo the forall). If both 'a' and 'b'
both scoped over the RHS, they'd get unified and so cannot stand
for distinct type variables. One could *imagine* allowing this:
x2 :: forall a. a->a
y2 :: forall a. a->a
(x2,y2) = strange
using the very same type variable 'a' in both signatures, so that
a single 'a' scopes over the RHS. That seems defensible, but odd,
because though there are two type signatures, they introduce just
*one* scoped type variable, a.
7) Possible extension. We might consider allowing
\(x :: [ _ ]) -> <expr>
where "_" is a wild card, to mean "x has type list of something", without
naming the something.
|
| | |
|
| |
|
|
| |
Fix build on 5.04.x again
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
GHC.runStmt: run the statement in a new thread to insulate the
environment from bad things that the user code might do, such as fork
a thread to send an exception back at a later time. In order to do
this, we had to keep track of which thread the ^C exception should go
to in a global variable.
Also, bullet-proof the top-level exception handler in GHCi a bit;
there was a small window where an exception could get through, so if
you lean on ^C for a while then press enter you could cause GHCi to
exit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for UTF-8 source files
GHC finally has support for full Unicode in source files. Source
files are now assumed to be UTF-8 encoded, and the full range of
Unicode characters can be used, with classifications recognised using
the implementation from Data.Char. This incedentally means that only
the stage2 compiler will recognise Unicode in source files, because I
was too lazy to port the unicode classifier code into libcompat.
Additionally, the following synonyms for keywords are now recognised:
forall symbol (U+2200) forall
right arrow (U+2192) ->
left arrow (U+2190) <-
horizontal ellipsis (U+22EF) ..
there are probably more things we could add here.
This will break some source files if Latin-1 characters are being used.
In most cases this should result in a UTF-8 decoding error. Later on
if we want to support more encodings (perhaps with a pragma to specify
the encoding), I plan to do it by recoding into UTF-8 before parsing.
Internally, there were some pretty big changes:
- FastStrings are now stored in UTF-8
- Z-encoding has been moved right to the back end. Previously we
used to Z-encode every identifier on the way in for simplicity,
and only decode when we needed to show something to the user.
Instead, we now keep every string in its UTF-8 encoding, and
Z-encode right before printing it out. To avoid Z-encoding the
same string multiple times, the Z-encoding is cached inside the
FastString the first time it is requested.
This speeds up the compiler - I've measured some definite
improvement in parsing at least, and I expect compilations overall
to be faster too. It also cleans up a lot of cruft from the
OccName interface. Z-encoding is nicely hidden inside the
Outputable instance for Names & OccNames now.
- StringBuffers are UTF-8 too, and are now represented as
ForeignPtrs.
- I've put together some test cases, not by any means exhaustive,
but there are some interesting UTF-8 decoding error cases that
aren't obvious. Also, take a look at unicode001.hs for a demo.
|
