On Tue, Aug 10, 2010 at 11:14:39AM +0200, David Virebayre wrote:
This is actually the 3rd or 4th time someone has had this issue, clearly I need to improve the documentation or something. What I was
I don't think you have. It's my fault entirely. Being used to ghc, I didn't expect to have to specify anything on the command line. Other imports worked fine too : Data.List, Data.Maybe, Control.Monad, etc.
Don't be hard on yourself, like I said, several other people were bitten by this too. A difference between ghc and jhc here is that ghc has quite a few 'wired in' packages, for various reasons it needs the base it is compiled with to match the one it is shipped with and available to users, this is true of quite a few packages. It regularly comes up on the cabal lists that someone tries to upgrade them directly and all heck breaks loose. As a side effect, ghc has a very straightforward choice wen it comes to deciding which packages to automatically make available, since these packages can't be gotten rid of anyway, it might as well always export them. jhc has exactly zero 'wired in' libraries, you can replace everpthing from the ground up just by specifying a different set of libraries with --noauto and -p. It is possible and even likely that you will have multiple different libraries that export 'Prelude' for instance, not just haskell98 and haskell2010 but an embedded system may very well want an alternate prelude that doesn't mention 'Integer' or 'Rational' because they are too heavyweight, an even more embedded system may want a prelude that is mainly in terms of unboxed types even. So, there really isn't a clear choice of what a 'natural' set of libraries to include is, other than the obvious 'haskell98' and 'haskell2010'. I will revisit this issue at some point in the future when I have more data on how jhc is actually used in the wild. I may make an explicit --dwim option (Do What I Mean) that will tell jhc it is allowed to make educated guesses about what the user meant, but that won't be for a while and I am hesitant to introduce such heuristic logic into jhc when there are external tools (franchise) that do it and more better. 'jhc -v --list-libraries' gives a huge amount of info suitable for an external dependency chaser tool.
I don't want to do the stateful thing ghc does with package registration and exposed/hidden packages and whatnot, it always felt fairly hacky. In jhc you get what you specify on the command line and thats it. (though, you can always create custom profiles in your targets.ini file)
But the drawback is every time you add an import from a new library, you have to also change your compile script. Not a big deal though.
Yeah, you end up doing the same thing with ghc if you try to write build scripts that are portable to other peoples systems, you can't know a priori what packages they have exposed, so you have to do a -hide-all-packages then explicitly import what you need with -package. So it isn't that much worse than ghc in this regard.
P.S. The cool thing is that the stripped executable is 79588 bytes with jhc vs 608036 with ghc !
Cool! :) -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/