Parsec -- Module not found
Hello, I've tried a small program that uses parsec, but I couldn't get it to compile : david@pcdavid:/data/code/edimail$ jhc -C DecVersBL.hs jhc -C DecVersBL.hs jhc 0.7.6 (0.7.6-3) Finding Dependencies... Using Ho Cache: '/home/david/.jhc/cache' DecVersBL [DecVersBL.hs] Error: Module not found: Text.ParserCombinators.Parsec Error: Module not found: Text.ParserCombinators.Parsec.Char Error: Module not found: Text.ParserCombinators.Parsec.Combinator I've looked into /home/david/download/jhc-0.7.6/lib/ext/parsec.cabal, exposed modules are Text.ParserCombinators.Parsec.xxxx, which is what I tried to import. Just in case, I've also tried the simpler names Text.Parsec, etc. jhc --list-libraries does list parsec-2.1.0.1 I've tried to find Parsec on the disk hoping it'd give me a clue about what to import, but I only found /usr/local/share/jhc-0.7/parsec-2.1.0.1.hl which doesn't help at all. There must be something really stupid I'm missing here. Help ! David.
On Tue, Aug 10, 2010 at 10:08:07AM +0200, David Virebayre wrote:
I've tried a small program that uses parsec, but I couldn't get it to compile :
david@pcdavid:/data/code/edimail$ jhc -C DecVersBL.hs jhc -C DecVersBL.hs jhc 0.7.6 (0.7.6-3) Finding Dependencies... Using Ho Cache: '/home/david/.jhc/cache' DecVersBL [DecVersBL.hs] Error: Module not found: Text.ParserCombinators.Parsec Error: Module not found: Text.ParserCombinators.Parsec.Char Error: Module not found: Text.ParserCombinators.Parsec.Combinator
I've looked into /home/david/download/jhc-0.7.6/lib/ext/parsec.cabal, exposed modules are Text.ParserCombinators.Parsec.xxxx, which is what I tried to import.
Just in case, I've also tried the simpler names Text.Parsec, etc.
jhc --list-libraries does list parsec-2.1.0.1
I've tried to find Parsec on the disk hoping it'd give me a clue about what to import, but I only found /usr/local/share/jhc-0.7/parsec-2.1.0.1.hl which doesn't help at all.
There must be something really stupid I'm missing here.
are you passing '-p parsec' on the command line? it is the equivalent of ghc's -package flag more or less. 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 thinking of was to have it look for unrecognized modules in available packages and provide a better error message, something like: "module Text.ParserCombinators.Parsec not found, however it is available in the parsec-2.1.0.1 package, did you forget to put '-p parsec' on the command line?" 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) John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
Yes I can confirm it's just a missing package, "jhc -p parsec ..." works fine for me. Regarding the documentation it was quite clear to me and it was relatively near the top of the page so it's not hard to miss, how about a feature similar to "ghc --make"? that would be quite useful because using more than 3/4 libraries can get unwieldy although I have no idea the complexity of implementing it. ----------------------------------------
Date: Tue, 10 Aug 2010 01:25:36 -0700 From: john@repetae.net To: jhc@haskell.org Subject: Re: [jhc] Parsec -- Module not found
On Tue, Aug 10, 2010 at 10:08:07AM +0200, David Virebayre wrote:
I've tried a small program that uses parsec, but I couldn't get it to compile :
david@pcdavid:/data/code/edimail$ jhc -C DecVersBL.hs jhc -C DecVersBL.hs jhc 0.7.6 (0.7.6-3) Finding Dependencies... Using Ho Cache: '/home/david/.jhc/cache' DecVersBL [DecVersBL.hs] Error: Module not found: Text.ParserCombinators.Parsec Error: Module not found: Text.ParserCombinators.Parsec.Char Error: Module not found: Text.ParserCombinators.Parsec.Combinator
I've looked into /home/david/download/jhc-0.7.6/lib/ext/parsec.cabal, exposed modules are Text.ParserCombinators.Parsec.xxxx, which is what I tried to import.
Just in case, I've also tried the simpler names Text.Parsec, etc.
jhc --list-libraries does list parsec-2.1.0.1
I've tried to find Parsec on the disk hoping it'd give me a clue about what to import, but I only found /usr/local/share/jhc-0.7/parsec-2.1.0.1.hl which doesn't help at all.
There must be something really stupid I'm missing here.
are you passing '-p parsec' on the command line? it is the equivalent of ghc's -package flag more or less.
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 thinking of was to have it look for unrecognized modules in available packages and provide a better error message, something like:
"module Text.ParserCombinators.Parsec not found, however it is available in the parsec-2.1.0.1 package, did you forget to put '-p parsec' on the command line?"
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)
John
-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ _______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc
On Tue, Aug 10, 2010 at 08:35:34AM +0000, Korcan Hussein wrote:
Yes I can confirm it's just a missing package, "jhc -p parsec ..." works fine for me. Regarding the documentation it was quite clear to me and it was relatively near the top of the page so it's not hard to miss, how about a feature similar to "ghc --make"? that would be quite useful because using more than 3/4 libraries can get unwieldy although I have no idea the complexity of implementing it.
Actually, jhc does do the equivalent of ghc's --make always, how it differs is that jhc always behaves like ghc if it is given the -hide-all-packages flag. GHC packages are somewhat complicated, there are a few different things that need to happen to get them to work, first you need to drop the files into an appropriate directory, then you need to use ghc-pkg to register your package, which writes to a config file telling ghc where it can find the package, then you need to 'expose' the package, so that ghc can see it. This works fine when your exposed packages just happen to be exactly what you want. But as soon as you have multiple versions of ghc installed or some libraries installed globally and some installed per user or you have multiple packages that implement the same API that you want to choose between things get tricky. Basically, when you need to do "interesting" things with ghc, it gets fairly complicated. In fact, to write a portable ghc build file you pretty much always have to do -hide-all-packages then explicitly list the ones you want anyway. Not that these things are impossible in ghc, they are just somewhat complicated and require special knowledge of how ghc-pkg works. For jhc I wanted a much simpler model, similar to the C model. Libraries just need to be findable by jhc (meaning they are in a directory it searches in or specified by -L on the command line) and exactly what you specify by '-p' along with what the targets.ini specifies are what are available for importing. Being able to fully describe jhcs library model in a single sentence seemed more useful to me than making a certain common case that is somewhat brittle easier. After all, once you know the once sentence description of how jhc works you can figure everything out. However, I still get stuck in "ghc dependency hell" occasionally and find myself having to re-install packages. Also, note that you only need to specify the '-p' for packages that you _directly_ use, for instance, even though 'containers' uses 'applicative' in its implemenation, you only need -pcontainers to use it. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Tue, Aug 10, 2010 at 10:25 AM, John Meacham
are you passing '-p parsec' on the command line? it is the equivalent of ghc's -package flag more or less.
My bad, I didn't know I had to do that. I apologise for wasting your time, as indeed the User manual makes it clear. I could have saved myself quite some time, had I read it. So it compiles and works with the command line.
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.
thinking of was to have it look for unrecognized modules in available packages and provide a better error message, something like:
That'd be cool, but I'm sure there's many things higher on the priority list. Fools like me just have to read the (adequate) existing documentation.
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. David. P.S. The cool thing is that the stripped executable is 79588 bytes with jhc vs 608036 with ghc !
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/
participants (3)
-
David Virebayre -
John Meacham -
Korcan Hussein