November 2009 - jhc - Haskell.org

jhc-0.7.1 and parsec-2.1.0.1
by Christian Maeder 19 Nov '09

19 Nov '09

Hi, I've tried to compile (part of) parsec-2.1.0.1 with jhc-0.7.1 and Parsec.Combinator had several problems with do-expression as infix arguments, which should be simple to fix for you. I.e. do{ p; return ()} <|> return () needed explicit parenthesis: (do{ p; return ()}) <|> return () (also if layout is used instead of curly braces) Cheers Christian name: parsec version: 2.1.0.1 exposed-modules: Text.ParserCombinators.Parsec.Error, Text.ParserCombinators.Parsec.Char, Text.ParserCombinators.Parsec.Combinator, Text.ParserCombinators.Parsec.Pos, Text.ParserCombinators.Parsec.Prim, Text.ParserCombinators.Parsec

3 7

Building cabal packages
by Chris Eidhof 17 Nov '09

17 Nov '09

Hey everyone, What's the way to build a cabalized package with jhc? I tried the following: > hc --build-hl Yampa.cabal yampa-0.9.2.3.hl > jhc --build-hl Yampa.cabal yampa-0.9.2.3.hl > jhc 0.7.3 (-n 0.7.2-40 > ) > Creating library from description file: "Yampa.cabal" > Reading: "Yampa.cabal" > Finding Dependencies... > Using Ho Cache: '/Users/chris/.jhc/cache' > Typechecking... > Compiling... > Writing Library: Yampa-0.9.2.3.hl But I don't think jhc actually compiled something, or it was *really* fast. I tried copying that .hl file to my JHC_LIBRARY_PATH, but when I invoke JHC with "-pyampa" it still won't find it. I'm a bit lost... -chris

3 6

containers package
by Chris Eidhof 16 Nov '09

16 Nov '09

It seems like JHC won't compile the darcs version of the containers library. After removing some pragmas, it failed to compile Data.Sequence at some quite normal-looking datatype. It fails with a parse error, I'm not sure why, but I'll investigate it later. For now I'm using the containers 0.2.0.1 version, which compiles just fine. -chris

2 1

Compiling JHC on OS X
by Chris Eidhof 16 Nov '09

16 Nov '09

Hey all, I'm trying to compile JHC on OS X. However, when I do a 'make jhc', I got the following error: > make jhc > perl ./utils/opt_sets.prl -n src/FlagDump.flags src/FlagDump.flags > > src/FlagDump.hs > Use of uninitialized value in hash element at ./utils/opt_sets.prl > line 44, <> line 84. > perl ./utils/opt_sets.prl -n src/FlagOpts.flags src/FlagOpts.flags > > src/FlagOpts.hs > Use of uninitialized value in hash element at ./utils/opt_sets.prl > line 44, <> line 45. > Use of uninitialized value in hash element at ./utils/opt_sets.prl > line 44, <> line 45. > happy -a -g -c src/FrontEnd/HsParser.y -o src/FrontEnd/HsParser.hs > unused rules: 2 > shift/reduce conflicts: 73 > reduce/reduce conflicts: 23 > sed -e 's/^{-# OPTIONS[A-Z_]*/{-# OPTIONS_GHC -w /' -i src/FrontEnd/ > HsParser.hs > sed: -i may not be used with stdin > make: *** [src/FrontEnd/HsParser.hs] Error 1 > make: *** Deleting file `src/FrontEnd/HsParser.hs' I fixed that by adding the extension to sed -i (I've attached a patch for that, my sendmail is broken). For future reference: I had some problems installing readline (using fink's readline). There's a thread [1] on haskell-café that solves that. After changing the line and installing readline, it started compiling. After a while, the compiler stopped with: > src/E/Subst.hs:143:22: > No instance for (T.Traversable (Lit TVr)) This was because I had an old version of Drift installed. I didn't see an error, it should probably fail as early as possible and notify me that I had an old version that didn't support deriving Traversable. Finally, JHC was compiled! When compiling the libraries, however, it failed again: > lib/containers/Data/Sequence.hs:312:16: Parse error > make[1]: *** [containers-0.2.0.hl] Error 1 Is somebody already working on that? If not, I'd be happy to dive in and fix it. (BTW, the culprit is the following line:) > {-# SPECIALIZE INLINE deep :: Digit (Elem a) -> FingerTree (Node > (Elem a)) -> Digit (Elem a) -> FingerTree (Elem a) #-} Thanks, -chris [1]: http://www.haskell.org/pipermail/libraries/2009-May/011597.html

1 0

Monad.ST
by Henning Thielemann 16 Nov '09

16 Nov '09

Before looking into the actual source code of the ST monad, I thought that ST must be something like newtype ST s a = ST (IO a) where the strict ST monad is based on normal IO bind function and lazy ST monad also uses unsafeInterleaveIO. Then runST would be just an unsafePerformIO. However when looking into http://darcs.haskell.org/packages/st it is in Control.Monad.ST.Lazy newtype ST s a = ST (State s -> (a, State s)) data State s = S# (State# s) and in Hugs.ST: newtype ST s a = ST (forall r. (a -> r) -> r) Both GHC and Hugs seem to use primitives, that are not available in JHC. Would my IO definition above be correct, at all? It seems that much of the code in the 'st' package could not be re-used in JHC.

3 9

Re: [jhc] Monad.ST
by Henning Thielemann 15 Nov '09

15 Nov '09

On Sun, 15 Nov 2009, Isaac Dupree wrote: > Henning Thielemann wrote: >> >> It compiles, but I have not tested any program that uses it. Even with >> simplest examples using storablevector it depends largely on fortune whether >> they run or crash. So no chance to make reliable statements about something >> more complex. > > hmm, I looked at the code. I don't quite understand lazy ST, but I don't > think that version you made is correct. The writes (and reads) really may > not be re-ordered based on which data is demanded when. You are right. I only thought about newSTRef's for which the order is not important. Yes, we also have to assert that writes are in order and reads remain between adjacent writes. Once I solved a similar problem in the 'lazyio' package. I defined IO actions in a way, that triggering one action also requires to execute all previous actions. This should also work for ST but it is somehow overly strict. E.g. do a <- newSTRef 'a' b <- newSTRef 'b' writeSTRef a 'c' writeSTRef b 'd' can be re-ordered to do b <- newSTRef 'b' writeSTRef b 'd' a <- newSTRef 'a' writeSTRef a 'c' That is, maximum laziness would be achieved, if there would be a state-thread for every reference.

1 0

strange crashes and changes in performance
by Henning Thielemann 15 Nov '09

15 Nov '09

I'm playing around with a simple program that fills a buffer and writes that to disk. The first variant is strange since it becomes much more than twice as slow, when the test runs twice: http://code.haskell.org/storablevector/speedtest/SpeedTestExpSlow.hs The second variant is strange, because if I use allocaArray instead of allocaBytes then it crashes. However, when I run the test twice, it works. http://code.haskell.org/storablevector/speedtest/SpeedTestExpCrashAllocaArr…

1 0

allowing unqualified method names in instance declarations
by Henning Thielemann 14 Nov '09

14 Nov '09

The attached patch shall help accepting an instance declaration like > import qualified Custom > > instance Custom.Class T where > methodA = ... > methodB = ... by translating it to > instance Custom.Class T where > Custom.methodA = ... > Custom.methodB = ... I don't know, whether this also works if you do > import qualified Custom hiding (methodA, methodB, ) John recently sent two patches to jhc(a)haskell.org, that are not present in the darcs repository. Do they need some confirmation? They work for me, as far as I can judge.

3 4

ignore optimizer phase information for INLINE pragmas as available in GHC
by Henning Thielemann 14 Nov '09

14 Nov '09

In low-level packages like bytestring and storablevector we have pragmas like {-# INLINE [1] func #-} The attached patch ignores the number, that specifies the optimizer phase where inlining shall happen. Ignoring that information is certainly not the best way, since an "inline only in phase x" may be meant as "better inline too seldom than too often". But this way I might get bytestring compiled without many modifications. At least I like to give a warning, when phase information is ignored, but I could not get that for now. Now when compiling Data.ByteString I am lost at: ./Data/ByteString.hs:1942 - Error: Unknown name: illegalOperationErrorType ./Data/ByteString.hs:1942 - Error: Unknown name: mkIOError cabal: Error: some packages failed to install: bytestring-0.9.1.5 failed during the building phase. The exception was: I don't know what the current state of exceptions in JHC is.

2 3

darcs patch: fix rewriting of OPTIONS pragma generated by new versi...
by John Meacham 14 Nov '09

14 Nov '09

Sat Nov 14 14:54:22 PST 2009 John Meacham <john(a)repetae.net> * fix rewriting of OPTIONS pragma generated by new versions of happy

1 0