- 26 Mar, 2007 2 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
-
- 23 Mar, 2007 3 commits
-
-
simonpj@microsoft.com authored
This fixes Trac #1065. The fix is just to emit a decent error message rather than crash. The situation is this: f x = ... [d| $(..stuff..); f x = v :: T |] ... TH wants to rename and typecheck the bracket; but it can't run the nested splice yet. That seems hard, because we know nothing about v, T, which are, presumably bound by the splice. The original TH paper says this isn't allowed, and now it's checked for properly (in the parser, in fact) rather than causing a crash. In the fullness of time we might want to do something more flexible, but not now.
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
- 22 Mar, 2007 6 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
sven.panne@aedion.de authored
-
simonpj@microsoft.com authored
This patch adds a flag -ddump-mod-cycles to the "ghc -M" dependency analyser. The effect of ghc -M -ddump-mod-cycles is to dump a list of cycles foud in the module graph. The display is trimmed so that only dependencies within the cycle are shown; and the list of modules in a cycle is itself sorted into dependency order, so that it is easy to track the chain of dependencies. Open question: should the flag be "-ddump-mod-cycles" or "-optdep-dump-mod-cycles"? For this reason I have not yet added to the documentation.
-
simonpj@microsoft.com authored
-
- 21 Mar, 2007 1 commit
-
-
simonpj@microsoft.com authored
Hs-boot files can contain instance declarations, but Duncan used this feature for the first time today, and it didn't quite work. I'm not sure whether it worked before; anyway it does now. The point is that the hs-boot file advertises an instance for, say, Num Int, with the arbitrary name $fx1. The main module declares Num Int, and gives it the name, say, $f3. So we need to generate a declaration $fx1 = $f3 to make it all line up. And (this is the bit that was wrong) we need to make that new binding visible to imported unfoldings that mention $fx1.
-
- 18 Mar, 2007 1 commit
-
-
red5_2@hotmail.com authored
Gcc 4 is doing more clever optimizations than earlier gccs. These changes let ghc compile and run on ia64 with gcc 4.0.3. Register stack frames are enlarged so that all functions use the same size stack frame. The code to mangle tail calls has been cleaned up and made more general. Additional floating-point and special-purpose registers used by GCC are saved upon entering the STG runtime. More general handling of NOP instructions. Handling of functions with multiple epilogues or no epilogue.
-
- 17 Mar, 2007 1 commit
-
-
red5_2@hotmail.com authored
Tail-calls now branch to the end of the function after the call. This stops gcc from trying to move instructions into the space immediately after the call, which confuses the mangler.
-
- 21 Mar, 2007 5 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
- 20 Mar, 2007 1 commit
-
-
simonpj@microsoft.com authored
-
- 19 Mar, 2007 1 commit
-
-
simonpj@microsoft.com authored
-
- 17 Mar, 2007 1 commit
-
-
Ian Lynagh authored
-
- 16 Mar, 2007 4 commits
-
-
simonpj@microsoft.com authored
Merge to 6.6 branch. Test case is dsrun014. Note [Desugaring seq] cf Trac #1031 ~~~~~~~~~~~~~~~~~~~~~ f x y = x `seq` (y `seq` (# x,y #)) The [CoreSyn let/app invariant] means that, other things being equal, because the argument to the outer 'seq' has an unlifted type, we'll use call-by-value thus: f x y = case (y `seq` (# x,y #)) of v -> x `seq` v But that is bad for two reasons: (a) we now evaluate y before x, and (b) we can't bind v to an unboxed pair Seq is very, very special! So we recognise it right here, and desugar to case x of _ -> case y of _ -> (# x,y #) The special case would be valid for all calls to 'seq', but it's only *necessary* for ones whose second argument has an unlifted type. So we only catch the latter case here, to avoid unnecessary tests.
-
simonpj@microsoft.com authored
This patch improves the misleading error message reported in Trac #1133. Please merge the patch to the 6.6.1 branch.
-
simonpj@microsoft.com authored
This patch refactors TcRnDriver to make the top-level structure easier to understand. The change was driven by Trac #924, and this patch fixes that bug. When comparing a module against its hs-boot file, we must ensure that the module exports everything that the hs-boot file exports.
-
simonpj@microsoft.com authored
-
- 15 Mar, 2007 3 commits
-
-
sven.panne@aedion.de authored
ATTENTION: Packagers should read the following stuff carefully! GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the one hand this is quite handy, avoiding lots of tiny native packages, but OTOH this leads to a few problems: * The tools are not always identical in functionality. * The tools fight for a global generic name like "/usr/bin/runhaskell". These problems are not new and not unique to Haskell implementations, so for *nix-based system there is a tool called update-alternatives which handles those cases. The idea is as follows: * Each program/man page/etc. installs itself with a very specific name like /usr/bin/hsc2hs-ghc or /usr/share/man/man1/lua5.1.1.gz, so nothing clashes. * The (un-)installation scripts call update-alternatives to notify the system about new alternatives for a generic tool/manpage/etc. * Alternatives can be grouped together ("link groups"), so e.g. switching from Sun's Java to Kaffe switches compiler, JRE, manpages etc. together. Alas, this doesn't work well with the Haskell implementations yet, because they come with different sets of tools (in addition to runFOO): GHC: hsc2hs Hugs: hsc2hs, cpphs nhc: cpphs Either these tools should be disentangled fromt the Haskell implementations or all implementations should offer the same set. Opinions and recommendations on this topic are highly welcome. * This mechanism can be used to easily switch between several versions of the same implementation, too, but we are not yet fully prepared for that. As a first step, GHC now installs hsc2hs as 'hsc2hs-ghc' and does *not* install runhaskell directly anymore, only runghc. hsc2hs and runhaskell are created via update-alternatives now. What is currently missing is a mechanism for platforms like Windows and probably Mac OS X.
-
simonpj@microsoft.com authored
See Trac #1200 This is a somewhat experimental fix. I'm not sure we want it in 6.6.1 The idea is explained in Note [Default unitTy] in TcSimplify. In interative mode (or with -fextended-default-rules) we add () as the first type we try when defaulting. This has very little real impact, except in the following case. Consider: Text.Printf.printf "hello" This has type (forall a. IO a); it prints "hello", and returns 'undefined'. We don't want the GHCi repl loop to try to print that 'undefined'. The neatest thing is to default the 'a' to (), rather than to Integer (which is what would otherwise happen; and then GHCi doesn't attempt to print the (). So in interactive mode, we add () to the list of defaulting types.
-
sven.panne@aedion.de authored
With this patch, one can define the degree of build parallelism via a 'jobs' rpm variable. A comfortable way to use this is having a ~/.rpmmacros file with a line like: %jobs 2 Alternatively, one could use a '--define "jobs 2"' command line flag for rpmbuild. On a Core 2 Duo using 2 jobs brings down the time for a full build including extralibs from 36m to 27m. If 'jobs' is not defined, a normal sequential build is done, following the usual conventions on e.g. openSUSE.
-
- 14 Mar, 2007 11 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
Ian Lynagh authored
Patch from Marc Weber in http://www.haskell.org/pipermail/glasgow-haskell-users/2007-February/011998.html
-
sven.panne@aedion.de authored
-
sven.panne@aedion.de authored
-
sven.panne@aedion.de authored
-
sven.panne@aedion.de authored
-
sven.panne@aedion.de authored
-
sven.panne@aedion.de authored
-
sven.panne@aedion.de authored
-
sven.panne@aedion.de authored
-