- 25 Jul, 2006 5 commits
-
-
Simon Marlow authored
The I# constructor is always removed when we make a unique later anyway, so this just saves a bit of time and allocation.
-
Simon Marlow authored
-
Simon Marlow authored
Now that the module restriction has been lifted, the auto-hiding is mostly not required. GHC itself automatically hides old versions of a package.
-
Simon Marlow authored
This patch pushes through one fundamental change: a module is now identified by the pair of its package and module name, whereas previously it was identified by its module name alone. This means that now a program can contain multiple modules with the same name, as long as they belong to different packages. This is a language change - the Haskell report says nothing about packages, but it is now necessary to understand packages in order to understand GHC's module system. For example, a type T from module M in package P is different from a type T from module M in package Q. Previously this wasn't an issue because there could only be a single module M in the program. The "module restriction" on combining packages has therefore been lifted, and a program can contain multiple versions of the same package. Note that none of the proposed syntax changes have yet been implemented, but the architecture is geared towards supporting import declarations qualified by package name, and that is probably the next step. It is now necessary to specify the package name when compiling a package, using the -package-name flag (which has been un-deprecated). Fortunately Cabal still uses -package-name. Certain packages are "wired in". Currently the wired-in packages are: base, haskell98, template-haskell and rts, and are always referred to by these versionless names. Other packages are referred to with full package IDs (eg. "network-1.0"). This is because the compiler needs to refer to entities in the wired-in packages, and we didn't want to bake the version of these packages into the comiler. It's conceivable that someone might want to upgrade the base package independently of GHC. Internal changes: - There are two module-related types: ModuleName just a FastString, the name of a module Module a pair of a PackageId and ModuleName A mapping from ModuleName can be a UniqFM, but a mapping from Module must be a FiniteMap (we provide it as ModuleEnv). - The "HomeModules" type that was passed around the compiler is now gone, replaced in most cases by the current package name which is contained in DynFlags. We can tell whether a Module comes from the current package by comparing its package name against the current package. - While I was here, I changed PrintUnqual to be a little more useful: it now returns the ModuleName that the identifier should be qualified with according to the current scope, rather than its original module. Also, PrintUnqual tells whether to qualify module names with package names (currently unused). Docs to follow.
-
Simon Marlow authored
-
- 06 Jul, 2006 2 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
-
- 04 Jul, 2006 7 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
- 24 Jul, 2006 1 commit
-
-
Simon Marlow authored
In all cases the namespace is known from the context, so this saves 1 byte per variable binding/occurrence (a few percent per iface file).
-
- 22 Jul, 2006 2 commits
-
-
simonpj@microsoft.com authored
In Haskell 98, pattern bindings are generalised. Thus in (f,g) = (\x->x, \y->y) both f and g will get polymorphic types. I have become convinced that generalisation for pattern-bound variables is just a bridge toof far. It is (I claim) almost never needed, and it adds significant complication. (All the more so if we add bang patterns.) So the flag -fmono-pat-binds switches off generalisation for pattern bindings. (A single variable is treated as a degnerate funtction binding.) Furthremore, as an experiment, I'm making it the default. I want to see how many progarms fail with monomorphic pattern bindings. You can recover the standard behaviour with -fno-mono-pa-binds.
-
simonpj@microsoft.com authored
Don Stewart and Duncan Coutts encountered the following situation. f = <rhs> {-# RULES f ... #-} where f is not exported, but appears in the inlinings of other functions that are exported. Then what happened was that the desugarer produced this: M.f = f f = <rhs> where the rules get attached to the M.f. But since M.f's RHS is trivial (just f) it was unconditionally inlinined at all its call sites, thereby losing the RULES attached to it. This *is* a fragile aspect of rules. However this fix solves the problem by instead generating f = M.f M.f = <rhs> A pretty small chanage to the desugarer does the job. It still feels a little fragile, bt it's certainly more robust than before.
-
- 21 Jul, 2006 2 commits
-
-
Simon Marlow authored
Don't know how I managed to use this before... maybe a different regex library.
-
Simon Marlow authored
-
- 19 Jul, 2006 1 commit
-
-
simonmar@microsoft.com authored
-
- 17 Jul, 2006 1 commit
-
-
David Himmelstrup authored
-
- 14 Jul, 2006 2 commits
-
-
simonpj@microsoft.com authored
MERGE TO STABLE I'd forgotten to compare the per-instance overlap flag when comparing interface files, and that meant that consequential recompilations weren't being triggered when the only change was to add -fallow-overlapping-instances Fixes Trac bug #824
-
simonpj@microsoft.com authored
-
- 12 Jul, 2006 4 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
This experimental flag, -fdicts-cheap, makes a let-binding that bind a value of dictionary type look cheap. That in turn leads to more eta expansion. Instead of f = /\a. \(d1:Ord a). let d2:Ord [a] = dfOrd a d1 in \(x:a). <stuff> which has arity 1, you get f = /\a. \(d1:Ord a). \(x:a). let d2:Ord [a] = dfOrd a d1 in <stuff> Now f has arity 2. This can cretainly waste dictionary-construction work, if f is partially applied to its dictionary argument. However it has knock-on effects. Because f has arity 2, we won't float (f Int d) out of \x. h (f Int d) Floating f out of this lambda makes it impossible for an h/f fusion rule to fire; and this unexpected loss of RULE application was the immediate reason for implementing this flag. (Roman Leshchinskiy came across this when working on array fusion.) I've implemented the change only in CoreUtils.arityType, which only affects eta expansion. I thought of putting the change in exprIsCheap, which is a more systematic place (the former calls the latter) but a) I wanted this under flag control, and the flags are not readily available to all callers of exprIsCheap b) I'm not 100% convinced that this change is a good idea, so it's reasonable to do the narrowest change that solves the immediate problem.
-
Malcolm.Wallace@cs.york.ac.uk authored
-
Simon Marlow authored
-
- 06 Jul, 2006 1 commit
-
-
Jan Rochel authored
-
- 10 Jul, 2006 1 commit
-
-
Simon Marlow authored
There are still some fixes required to get the threaded RTS compilable with the NCG, and apparently there are problems on 32-bit archs too.
-
- 24 Jun, 2006 1 commit
-
-
Ian Lynagh authored
-
- 02 Jul, 2006 2 commits
-
-
Jan Rochel authored
HEAD doesn't z-encode external-core output (unlike 6.4). I suppose, that this is unwanted behaviour. It probably results from this patch: ======================================================================== Fri Jan 6 17:30:19 CET 2006 simonmar * [project @ 2006-01-06 16:30:17 by simonmar] Add support for UTF-8 source files [...] 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. [...] ======================================================================== Greetings Jan
-
Jan Rochel authored
Hello, this is my first patch contributed to GHC. If there are any inadequacies about it (maybe like this introductory disclaimer), please let me know about it. So, the need for this patch arose, while I was involved with processing hcr files (external core output) and I noticed, that the output didn't fully conform to the specification [1]. No %local-tags were used, which turned out to be a real nuisance as it was not possible to determine which VDEFs can be erased in a further optimization process and which ones are exported by the module. Since the specification does not define the meaning of the %local-tag, I assume, it makes sense, that it tags all functions, that are not exported by the module. The patch does not fully comply to the specification, as in my implementation a local tag may appear before a VDEF but not before a VDEFG. [1] An External Representation for the GHC Core Language (DRAFT for GHC5.02), page 3, line 1 Greetings Jan
-
- 03 Jul, 2006 1 commit
-
-
Alec Berryman authored
darcs-all may now be run with any POSIX-compatible /bin/sh.
-
- 04 Jul, 2006 1 commit
-
-
duncan.coutts@worc.ox.ac.uk authored
say "{-# SOURCE #-}" rather than "{- SOURCE -}" in warning message. Fixes http://hackage.haskell.org/trac/ghc/ticket/812
-
- 03 Jul, 2006 1 commit
-
-
simonpj@microsoft.com authored
This appears to be a long-standing bug, discovered by BlueSpec (ravi@bluespec.com), Trac bug #795 The problem was that in an IP binding group, the dict bindings aren't necessarily in dependency order; and if they aren't we get a core-lint error. Test tc203 checks this case. (Though whether it shows up at all depends a bit on accidental factors of binding ordering.)
-
- 04 Jul, 2006 1 commit
-
-
Simon Marlow authored
Fixes #809
-
- 29 Jun, 2006 4 commits
-
-
Simon Marlow authored
static relative offsets (eg .long l1-l2) are restricted to 32 bits on x86-64 due to lack of support in the linker. The codegen, NCG and runtime work around this, using 32-bit offsets instead of 64. However, we were missing a workaround for vector tables, and it happened to work by accident because the offsets were always positive and resolved by the assembler. The bug was exposed by using the NCG to compile the RTS, where the offsets became negative, again by accident.
-
Simon Marlow authored
-
Simon Marlow authored
So that we can build the RTS with the NCG.
-
Simon Marlow authored
so that we can calculate deterministic offsets to some of the fields of Capability.
-