| 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.
|
| |
|
|
|
|
|
| |
Tweaks to get the GHC sources through Haddock. Doesn't quite work
yet, because Haddock complains about the recursive modules. Haddock
needs to understand SOURCE imports (it can probably just ignore them
as a first attempt).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-------------------------------------
Big upheaval to the way that constructors are named
-------------------------------------
This commit enshrines the new story for constructor names. We could never
really get External Core to work nicely before, but now it does.
The story is laid out in detail in the Commentary
ghc/docs/comm/the-beast/data-types.html
so I will not repeat it here.
[Manuel: the commentary isn't being updated, apparently.]
However, the net effect is that in Core and in External Core, contructors look
like constructors, and the way things are printed is all consistent.
It is a fairly pervasive change (which is why it has been so long postponed),
but I hope the question is now finally closed.
All the libraries compile etc, and I've run many tests, but doubtless there will
be some dark corners.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FastString cleanup, stage 1.
The FastString type is no longer a mixture of hashed strings and
literal strings, it contains hashed strings only with O(1) comparison
(except for UnicodeStr, but that will also go away in due course). To
create a literal instance of FastString, use FSLIT("..").
By far the most common use of the old literal version of FastString
was in the pattern
ptext SLIT("...")
this combination still works, although it doesn't go via FastString
any more. The next stage will be to remove the need to use this
special combination at all, using a RULE.
To convert a FastString into an SDoc, now use 'ftext' instead of
'ptext'.
I've also removed all the FAST_STRING related macros from HsVersions.h
except for SLIT and FSLIT, just use the relevant functions from
FastString instead.
|
| |
|
|
| |
Friday afternoon pet peeve removal: define (Util.notNull :: [a] -> Bool) and use it
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------
Change the treatment of the stupid
context on data constructors
-----------------------------------
Data types can have a context:
data (Eq a, Ord b) => T a b = T1 a b | T2 a
and that makes the constructors have a context too
(notice that T2's context is "thinned"):
T1 :: (Eq a, Ord b) => a -> b -> T a b
T2 :: (Eq a) => a -> T a b
Furthermore, this context pops up when pattern matching
(though GHC hasn't implemented this, but it is in H98, and
I've fixed GHC so that it now does):
f (T2 x) = x
gets inferred type
f :: Eq a => T a b -> a
I say the context is "stupid" because the dictionaries passed
are immediately discarded -- they do nothing and have no benefit.
It's a flaw in the language.
Up to now I have put this stupid context into the type of
the "wrapper" constructors functions, T1 and T2, but that turned
out to be jolly inconvenient for generics, and record update, and
other functions that build values of type T (because they don't
have suitable dictionaries available).
So now I've taken the stupid context out. I simply deal with
it separately in the type checker on occurrences of a constructor,
either in an expression or in a pattern.
To this end
* Lots of changes in DataCon, MkId
* New function Inst.tcInstDataCon to instantiate a data constructor
I also took the opportunity to
* Rename
dataConId --> dataConWorkId
for consistency.
* Tidied up MkId.rebuildConArgs quite a bit, and renamed it
mkReboxingAlt
* Add function DataCon.dataConExistentialTyVars, with the obvious meaning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------
Change
GlobalName --> ExternalName
LocalName -> InternalName
------------------------
For a long time there's been terminological confusion between
GlobalName vs LocalName (property of a Name)
GlobalId vs LocalId (property of an Id)
I've now changed the terminology for Name to be
ExternalName vs InternalName
I've also added quite a bit of documentation in the Commentary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Pet peeve removal / code tidyup, replaced various sub-optimal
uses of 'length' with something a bit better, i.e., replaced
the following patterns
* length as `cmpOp` length bs
* length as `cmpOp` val -- incl. uses where val == 1 and val == 0
* {take,drop,splitAt} (length as) bs
* length [ () | pat <- as ]
with uses of misc Util functions.
I'd be surprised if there's a noticeable reduction in running
times as a result of these changes, but every little bit helps.
[ The changes have been tested wrt testsuite/ - I'm seeing a couple
of unexpected breakages coming from CorePrep, but I'm currently
assuming that these are due to other recent changes. ]
- compMan/CompManager.lhs: restored 4.08 compilability + some code
cleanup.
None of these changes are HEADworthy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
----------------
Squash newtypes
----------------
This commit squashes newtypes and their coerces, from the typechecker
onwards. The original idea was that the coerces would not get in the
way of optimising transformations, but despite much effort they continue
to do so. There's no very good reason to retain newtype information
beyond the typechecker, so now we don't.
Main points:
* The post-typechecker suite of Type-manipulating functions is in
types/Type.lhs, as before. But now there's a new suite in types/TcType.lhs.
The difference is that in the former, newtype are transparent, while in
the latter they are opaque. The typechecker should only import TcType,
not Type.
* The operations in TcType are all non-monadic, and most of them start with
"tc" (e.g. tcSplitTyConApp). All the monadic operations (used exclusively
by the typechecker) are in a new module, typecheck/TcMType.lhs
* I've grouped newtypes with predicate types, thus:
data Type = TyVarTy Tyvar | ....
| SourceTy SourceType
data SourceType = NType TyCon [Type]
| ClassP Class [Type]
| IParam Type
[SourceType was called PredType.] This is a little wierd in some ways,
because NTypes can't occur in qualified types. However, the idea is that
a SourceType is a type that is opaque to the type checker, but transparent
to the rest of the compiler, and newtypes fit that as do implicit parameters
and dictionaries.
* Recursive newtypes still retain their coreces, exactly as before. If
they were transparent we'd get a recursive type, and that would make
various bits of the compiler diverge (e.g. things which do type comparison).
* I've removed types/Unify.lhs (non-monadic type unifier and matcher),
merging it into TcType.
Ditto typecheck/TcUnify.lhs (monadic unifier), merging it into TcMType.
|
| |
|
|
| |
More small changes
|
| |
|
|
| |
Mainly MkIface
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now Char, Char#, StgChar have 31 bits (physically 32).
"foo"# is still an array of bytes.
CharRep represents 32 bits (on a 64-bit arch too). There is also
Int8Rep, used in those places where bytes were originally meant.
readCharArray, indexCharOffAddr etc. still use bytes. Storable and
{I,M}Array use wide Chars.
In future perhaps all sized integers should be primitive types. Then
some usages of indexing primops scattered through the code could
be changed to then-available Int8 ones, and then Char variants of
primops could be made wide (other usages that handle text should use
conversion that will be provided later).
I/O and _ccall_ arguments assume ISO-8859-1. UTF-8 is internally used
for string literals (only).
Z-encoding is ready for Unicode identifiers.
Ranges of intlike and charlike closures are more easily configurable.
I've probably broken nativeGen/MachCode.lhs:chrCode for Alpha but I
don't know the Alpha assembler to fix it (what is zapnot?). Generally
I'm not sure if I've done the NCG changes right.
This commit breaks the binary compatibility (of course).
TODO:
* is* and to{Lower,Upper} in Char (in progress).
* Libraries for text conversion (in design / experiments),
to be plugged to I/O and a higher level foreign library.
* PackedString.
* StringBuffer and accepting source in encodings other than ISO-8859-1.
|
| |
|
|
|
|
| |
Commiting version of STG -> GOO that seems to compile PrelBase successfully.
Many other wibbles; esp. String handling.
|
| |
|
|
|
| |
Adding change that handles trivial use of primitives (compares,
integer arithmetic, etc) better when generating Java.
|
| |
|
|
| |
Commiting version of the STG->GOO code generator that works with fib.
|
| |
|
|
|
|
| |
Adding types to the names inside the GOO.
All needed for a langauge with unboxed types ...
|
| |
|
|
| |
More wibbles towards compiling data constructors and unboxing correctly.
|
| |
|
|
|
| |
Significant reworking of Java code generator, towards
getting unboxing working.
|
| |
|
|
|
|
|
| |
Fixing up names to make a reasonable use of Java packages.
This is just one of a number of steps before attacking the Prelude.
Fixing up the output order of the inner classes, making postprocessing easier.
|
| |
|
|
|
|
|
|
| |
Adding a field to the Method constructor, to allow methods
to say what they might raise. This is needed to actually
compile generated code.
Also, the generated code now imports haskell.runtime.*
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Wibble...
The corrected example is as follows:
myS :: (forall t t1 t2. (t -> t2 -> t1) -> (t -> t2) -> t -> t1)
[NoDiscard] __AL 3
myS
= \ @ t @ t1 @ t2 f :: (t -> t2 -> t1) g :: (t -> t2) x :: t -> f x (g x)
public class myS implements Code {
public Object ENTER () {
VM.COLLECT(3, this);
final Object f = VM.POP();
final Object g = VM.POP();
final Object x = VM.POP();
VM.PUSH(x);
VM.PUSH(new Thunk(new myS$1(g, x)));
return f;
}
}
class myS$1 extends Code {
final Object g;
final Object x;
public myS$1 (Object _g_, Object _x_) {
g = _g_;
x = _x_;
}
public Object ENTER () {
VM.PUSH(x);
return g;
}
}
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First attempt at at class lifter for the GHC GOO backend.
This included a cleanup of the Java/GOO abstract syntax
- Name is now a string, not a list of string
- Type is used instead of name in some places
(for example, with new)
- other minor tweeks.
Andy
---------
Example for myS f g x = f x (g x)
public class myS implements Code {
public Object ENTER () {
VM.COLLECT(3, this);
final Object f = VM.POP();
final Object g = VM.POP();
final Object x = VM.POP();
VM.PUSH(x);
VM.PUSH(new Thunk(new Code(g, x)));
return f;
}
}
class myS$1 {
final Object g;
final Object x;
public myS$1 (Object _g_, Object _x_) {
g = _g_;
x = _x_;
}
public Object ENTER () {
VM.PUSH(x);
return g;
}
}
|
|
|
Add support for Java generation, written in
a lightning day with Erik Meijer
ghc -J Foo.hs
will do the business, generating Foo.java
The code is in a new directory, javaGen/, so
you'll need to cvs update -d.
I've reorganised main/CodeOutput quite a bit; it
is now much much tidier, and will accommodate new
languages quite easily.
I've also fiddled with the flags that communicate
between the driver and hsc.
GONE: -S= -C=
NEW: -olang=xxx output language xxx
xxx can be: C, asm, java
-ofile=xxx put the output code in file xxx
BEWARE that I might have broken some of the more
cryptic stuff in ghc.lprl.
Simon
|
