OK, so the other day I decided to take GHC 7.0.1 for a spin. Suffice it to say, it definitely compiles stuff. So far, I've only tried running it in a Windows XP virtual machine with a single core, so I haven't been able to test what multicore performance is like. One thing that did interest me is the conflicting information about whether or not dynamic linking is supported on Windows. Half the User Guide claims that this /is/ supported, and the other half still contains statements that it is /not/ supported. So I thought I'd just go physically try it and see if it works. Well... it compiles stuff. Hello World goes from being 518KB to being a piffling 13KB. Which is nice. I almost didn't bother actually trying to /run/ the resulting binary... But when I did, I discovered that it immediately crashes, whining that it can't find the DLL it wants. So, out of the box, the Windows setup is broken. (Obviously the Windows section of the User Guide makes no mention of how DLLs are located; it only explains the situation for Linux and Mac OS. I especially liked the bit where it says that there are "three modes", and then proceeds to list only two...) In the interests of science, I wanted to see if I could make it run by just putting the necessary DLLs into the same folder as the binary. But first I had to /find/ them. I had expected to find a folder somewhere with all the DLLs in it... but no, the installer appears to have sprinkled them around the filesystem more or less at random. Some of them are in folders named for the package, some of them just sit in the root folder. After about 20 minutes of searching, I found the RTS DLL. Running the program, it now instantly crashes because of a /different/ DLL. This one didn't take quite so long to find (now that I know roughly where to look). I fixed that, and now the binary crashes with yet another missing DLL. And so on and so forth. In the end, Hello World required 5 DLLs. Better still, together these totalled 8MB of data. (!) So the distribution package is now about 16x bigger than with static linking. Oh joy. Clearly if you just want to distribute one executable binary, you're going to use static linking. (E.g., darcs.exe will hopefully remain statically linked.) But I suppose if I had a whole heap of Haskell programs then the extra complexity of delivering half a dozen DLLs might may off in terms of space reductions. And of course, on /my/ development box, I don't need a zillion redundant copies of the RTS code, etc. (Or at least, I won't if I can figure out how to make the programs able to actually /find/ the necessary DLLs...) Actually, of all the DLLs, only "base" is actually large - it's approximately 6MB on its own. GHC-Prim is 0.5MB, and the others are all relatively tiny. It feels slightly irritating that I need to inclide the FFI DLL when I'm not doing and FFI - but of course, the entire Haskell I/O subsystem /is/ doing FFI. Similarly, I'm not using arbitrary-precision integers, but various I/O operations return file sizes as Integer, so GMP must also be included. Neither of these things are actually especially large. It's rather confusing that the User Guide is out of date in so many places. (And not just regarding dynamic linking on Windows. For example, one section claims that "+RTS -f" will tell you what options are supported, but that actually yields "unknown RTS opion: -f". It seems that "-?" is the correct option name.) If I can get a suitable Linux VM going, I might have a go at contributing some updates. Just for completeness, I tried asking for dynamic linking with an older version of GHC (6.10, IIRC) - one that supports it on Linux but not Windows. I was expecting to get either "dynamic linking is not supported on this platform", or at worst "unknown option -dynamic". In fact, what I got was "gcc: cannot find file Main.dyn_hi". Oh, that's graceful failure then. >_< I did also briefly see if the LLVM backend would work under Windows. I wasn't entirely sure if LLVM comes with the installer binary or you need to get it seperately. (You might say "obviously it's seperate", but the installer already contains the entire GCC system, for example.) Attempting to use this resulted in a summary error message ("cannot run: opt") which doesn't make it especially clear that the problem is that LLVM isn't installed. Perhaps there's no better way of detecting this condition, I don't know, but something more illuminating would be nice. I briefly had a look at how to install LLVM, but it appears that you have to build it from source. This is not my idea of a fun time, so given the minimal speed difference, I just won't bother. I haven't had time to play with any of the other new good stuff in GHC 7. (The multicore performance, the new GC stuff, etc.)