RE: Curious behaviour of irrefutable pattern.
| I take it, then, that the answer to the question of under what | circumstances does the (error - non-termination) transformation | happen? is that GHC can choose among different bottoms that are | present in the program. It can't, however, willy-nilly convert my | error calls to bottom. (Or something more precise along the same | lines.) Yes, that's right, good point. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: inlining higher-order-functions?
| My example is complicated, so let me present a simpler analogy.
| Suppose I defined
|
| compose :: (b - c) - (a - b) - (a - c)
| compose f g = \x - f (g x)
|
| I can easily persuade GHC to inline 'compose'.
| But when 'compose' is applied to known arguments, I wish
| f and g to be inlined in the body of 'compose'.
| Is there a pragma that will do the trick?
| (I attempted to put an INLINE pragma in a where clause,
| but GHC was not amused.)
You can put inline pragmas on f and g, thus
frob = ...
{-# INLINE frob #-}
burk = ...
{-# INLINE burk #-}
wibble = compose from burk
Now compose will be inlined (assuming it too has an INLINE pragma), and then
frob, burk.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Curious behaviour of irrefutable pattern.
On 22/12/2006, at 7:14 PM, Simon Peyton-Jones wrote: | I take it, then, that the answer to the question of under what | circumstances does the (error - non-termination) transformation | happen? is that GHC can choose among different bottoms that are | present in the program. It can't, however, willy-nilly convert my | error calls to bottom. (Or something more precise along the same | lines.) Yes, that's right, good point. I've been following this thread with interest. But now I don't understand what the conclusion is. I thought Simon's earlier example showed that the semantics of GHC does not distinguish between an infinite loop and a call to error. Otherwise the strictness optimisation would be unsound. Mike, what do you mean by willy nilly convert my error calls to bottom? Cheers, Bernie. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
importing in place and packages
I'm compiling the files for package javavm with GHC 6.6 (using -package-name javavm). As part of the compilation process, I need a runnable program that uses the modules I've compiled in place: import JVMBoot But I get this error when compiling my Main module (ShowClasses.hs): ShowClasses.hs:23:1: Bad interface file: JVMBoot.hi Something is amiss; requested module main:JVMBoot differs from name found in the interface file javavm:JVMBoot Really I want to import javavm:JVMBoot, not main:JVMBoot. I tried this, but GHC doesn't like it (because it's not Haskell): import javavm:JVMBoot I tried compiling ShowClasses.hs with -package-name javavm. This let me compile, but then I get this on link: /usr/bin/ld: Undefined symbols: _ZCMain_main_closure ___stginit_ZCMain collect2: ld returned 1 exit status I tried adding a -main-is in the compile step, but this didn't help. Is there any way to create a main function that calls files imported in place that are in some package? I have the same issue when writing tests for my time package. -- Ashley Yakeley ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: importing in place and packages
The main program must be in package 'main', which is why compiling ShowClasses with -package-name javavm doesn't work. I'll modify the documentation to say this more clearly When you say import JVMBoot, and your javavm package is not installed, GHC thinks you mean JVMBoot from package main. The only way at the moment you can make GHC realise you mean JVMBoot from package javavm is to install it. You may say that's a bit silly -- after all, GHC can simply look at the interface file, and that is what you want here. I'll talk to Simon about whether that could be possible, but I'm guessing there's a good reason why not. Anyway, the solution for you is to install it. Cabal? There must be a well-understood process but I'm not the one to ask. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow- | [EMAIL PROTECTED] On Behalf Of Ashley Yakeley | Sent: 22 December 2006 10:44 | To: glasgow-haskell-users@haskell.org | Subject: importing in place and packages | | I'm compiling the files for package javavm with GHC 6.6 (using | -package-name javavm). As part of the compilation process, I need a | runnable program that uses the modules I've compiled in place: | |import JVMBoot | | But I get this error when compiling my Main module (ShowClasses.hs): | | ShowClasses.hs:23:1: | Bad interface file: JVMBoot.hi | Something is amiss; requested module main:JVMBoot differs | from | name found in the interface file javavm:JVMBoot | | Really I want to import javavm:JVMBoot, not main:JVMBoot. I tried this, | but GHC doesn't like it (because it's not Haskell): | | import javavm:JVMBoot | | I tried compiling ShowClasses.hs with -package-name javavm. This let | me compile, but then I get this on link: | | /usr/bin/ld: Undefined symbols: | _ZCMain_main_closure | ___stginit_ZCMain | collect2: ld returned 1 exit status | | I tried adding a -main-is in the compile step, but this didn't help. | | Is there any way to create a main function that calls files imported | in | place that are in some package? I have the same issue when writing | tests for my time package. | | -- | Ashley Yakeley | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: importing in place and packages
Simon Peyton-Jones wrote: Anyway, the solution for you is to install it. I can't install it, the package isn't finished being built at that point. Or perhaps I could find a way of installing the partial package to the user database. I build part of package javavm. Then I use that to build ShowClasses. Then I run ShowClasses to generate more source files. Then I use those to build the rest of javavm. -- Ashley Yakeley ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: importing in place and packages
Hmm. Ghc doesn't really give you a way to *run* a package which is so partly-built that you can't install it. That's perhaps not clever, but I think it's the current story. | point. Or perhaps I could find a way of installing the partial package | to the user database. That sounds plausible to me. | I build part of package javavm. Then I use that to build ShowClasses. | Then I run ShowClasses to generate more source files. Then I use those | to build the rest of javavm. Two packages, perhaps? S ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Curious behaviour of irrefutable pattern.
Bernie Pope [EMAIL PROTECTED] writes: ... Mike, what do you mean by willy nilly convert my error calls to bottom? Simon Peyton-Jones [EMAIL PROTECTED] writes: In general, GHC (like every other compiler that does strictness analysis) feels free to change non-termination into a call to 'error' and vice versa. One could change that, but a lot of programs would become less efficient as a result. I was concerned by the vice versa conversion--from an error call to non-termination. If more than one bottoms (say, a non-termination and an error call) are present in my program, I'm fine with getting any one of them. If I have only an error call, though, I do want to see an error message. An infinite loop would be unhelpful. So, I would consider it an unfriendly willy nilly convertion for GHC to generate code for: import System.Environment ( getArgs ) main = getArgs = putStrLn . head that failed to terminate when I passed no command-line arguments. -m ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Running GHC on the IBM Cell
Hello, I'm trying to get GHC to run on the Cell processor. That is, just on the PPU PowerPC side. The SPUs will continue to run C programs, managed and driven by a Haskell manager on the PPU. I'm mostly interested in GHC for its concurrency features (STM in particular). Not knowing much about GHC yet, here's what I would expect in the ideal situation. 1. The RTS is largely cross-platform already. I might have to make some minor tweaks, but for the most part it should compile out of the box. 2. I setup GHC to compile my .hs files to .hc files; the C intermediates. 3. These are hopefully cross-platform as well, instead of being tied to my GHC distribution's platform. 4. I compile the RTS and .hc files and link them all together. 5. Done. This raises a few questions... * Are the .hc files cross-platform? Or does a GHC compiled for PowerPC generate different intermediate C code than a GHC compiled for X86? Ideally the platform specifics are hidden inside the RTS and two different GHC builds will output identical .hc files. * How cross-platform is the RTS? I downloaded the source tarball and dropped it on top of my XP installation of GHC. I then generated a simple Hello World haskell .hc intermediate and tried to compile that and the RTS. Unfortunately I ran into problems because things like HAVE_WINDOWS_H and HAVE_SIGNALS_H were defined. I started manually editing the code to tweak the configuration but ran into more problems (signal_set_t doesn't exist on my platform, but can't be conditionally compiled. static arrays of unknown size (StgWordArray) make my compiler unhappy. Etcetera). At this point I figured I would stop and ask for some help first, before I invest a lot of energy in a dead-end path. There must be a simpler way. I read parts of the porting GHC to your platform documentation, but I believe it addresses a different problem. I don't want to recompile GHC itself. I want to run my existing GHC on my XP machine and output intermediate .hc files. I then feed these plus a cross-platform RTS to my Cell compiler to get a workable program. I suppose I need to regenerate the ghautoconf for my particular platform (rather than hand-tweaking the existing one). Unfortunately I'm not much of a Linux or Gnu toolset expert. I see a bunch of config.* and configure.* file in the root folder. I suppose I should read up on those a little more. I'll do my homework first. In the meanwhile, if anybody has any quick and simple advice to make this process smoother that would be greatly appreciated. Kind regards, Jaap Suter - http://www.jaapsuter.com Some more random questions... * ghautoconf.h and HsBaseConfig.h have similar #defines (like HAVE_WINDOWS_H). Is there a reason for that? I always need to update them in two places now. * After downloading the source tarball and unzipping over my XP GHC installation, I got both an 'include' and an 'includes' directory. This is somewhat confusing. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: inlining higher-order-functions?
Hello Norman, Friday, December 22, 2006, 8:23:57 AM, you wrote: compose :: (b - c) - (a - b) - (a - c) compose f g = \x - f (g x) ghc 6.6 added 'inline' function, see user docs. although only SPJ knows whether it can be used here: compose f g = inline (\x - f (g x)) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: LLVM back end
On Thu, Dec 21, 2006 at 12:54:50AM +0100, Wolfgang Thaller wrote: ad c) While they are supported in theory, I couldn't get LLVM to generate any tailcalls. Maybe I've done something wrong, maybe they're not really implemented yet. it seems that ghc could benefit from a tail-call elimination optimization, that turns them directly into loops. I have implemented it for jhc and it was not terribly difficult (though, not trivial) basically, I just refrained from lambda lifting any functions that were always applied in a fully saturated manner and called in tail-position. then when spitting out C, I just compile them directly into 'goto's. It seems to work well and subsumes turning jump-points directly into goto's rather than function calls as well. I actually do lambda lifting twice, once right before converting to grin, where I lambda lift everything that can never be directly jumped to because it occurs in an unsaturated call or in a lazy context (even if it is called outside of tail position in a strict context), then I optimize, then I lambda lift right before conversion to C any that wern't able to be turned into true jumps. the grin optimizations seem to be able to expose more tail-calls so make this two pass lambda lifting worth it. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
