January 2011 - jhc - Haskell.org

darcs patch: code cleanups
by John Meacham 28 Jan '11

28 Jan '11

Sat Jan 22 18:08:27 PST 2011 John Meacham <john(a)repetae.net> * code cleanups

1 0

How to fire jhc rules
by Facundo Domínguez 18 Jan '11

18 Jan '11

Dear haskellers, In learning to use rules with jhc 0.7.6-3, I am trying to compile the following test program with flags -f global-optimize -f rules, but it seems I cannot get rule "hf" to fire. I've compiled the program with ghc and the rule is applied in that case. -------------------------- {-# NOINLINE f #-} f x = x ++ "f" {-# NOINLINE h #-} h x = x++"h" {-# RULES "hf" forall x. h (f x) = x #-} main = putStr (h (f "1")) -------------------------- Rule "hf" is not preserving semantics so I can see if the rule is applied by executing the result. I would be thankful for any hint on how to get the rule applied as well as how to get jhc to report which rules it has applied during compilation. Best, Facundo

2 2

compiler errors/bugs with transformers
by Korcan Hussein 08 Jan '11

08 Jan '11

Hello, I have built the latest version of transformers package (so no multi-parameter type-classes) with the latest darcs version of jhc. When I "run" my monad transformer stack in main (and escape back into IO) I get an error message, I've attached a simplified example which reproduces the bug, I get the message: jhc: getType: EPi (x34075924::ELit (Jhc.Prim.Int::EPi (_::ESort *) (ESort *))) (ELit ((#2#) (ELit (Jhc.Prim.World__::ESort #)) (ELit (Jhc@.Absurd.*::ESort *))::ESort #)) If I use a records with foreign pointers for StateT/ReaderT and use get/ask I get 100s of error messages starting with: Typechecking... Compiling... Collected Compilation... -- typeAnalyzeMethods >>> Exception thrown >>> Before typeAnalyze-Main-AfterMethod theMain :: Jhc.Prim.World__ → Jhc.Prim.World__ theMain = λv1∷Jhc.Prim.World__. Jhc.IO.runMain () Main.main v1 Instance@.iJhc.Num.toInteger.Data.Word.Word32 :: Data.Word.Word32 → Integer Instance@.iJhc.Num.toInteger.Data.Word.Word32 = λv1∷Data.Word.Word32. case v1 of Word32# (v3∷bits32) → case W@.fInstance@.iJhc.Num.toInteger.Data.Word.Word32 v3 of v4∷bits<max> → Integer# v4;; Instance@.iForeign.Storable.poke.Graphics.UI.SDL.Color.Color :: Jhc.Addr.Ptr Graphics.UI.SDL.Color.Color → Graphics.UI.SDL.Color.Color → Jhc.Prim.IO () Instance@.iForeign.Storable.poke.Graphics.UI.SDL.Color.Color = λv1∷Jhc.Addr.Ptr Graphics.UI.SDL.Color.Color. λv2∷Graphics.UI.SDL.Color.Color. λv3∷Jhc.Prim.World__. case v2 of Graphics.UI.SDL.Color.Color (v5∷Data.Word.Word8) (v6∷Data.Word.Word8) (v7∷Data.Word.Word8) → W@.fInstance@.iForeign.Storable.poke.Graphics.UI.SDL.Color.Color v1 v5 v6 v7 v3; Jhc.Monad.=<< :: ∀f0∷* → *.∀a.∀b. (a → f0 b) → f0 a → f0 b Jhc.Monad.=<< = Λf0∷* → *.Λa.Λb.λJhc.Monad.97_f∷a → f0 b.λJhc.Monad.98_x∷f0 a. Jhc.Monad.>>= f0 a b Jhc.Monad.98_x Jhc.Monad.97_f Foreign.C.String.peekCAString :: Jhc.Addr.Ptr Foreign.C.Types.CChar → Jhc.Prim.IO String Foreign.C.String.peekCAString = λv1∷Jhc.Addr.Ptr Foreign.C.Types.CChar. λv2∷Jhc.Prim.World__. case v1 of Jhc.Addr.Ptr (v4∷bits<ptr>) → W@.fForeign.C.String.peekCAString v4 v2; Jhc.IO.runMain :: ∀a. Jhc.Prim.IO a → Jhc.Prim.World__ → Jhc.Prim.World__ Jhc.IO.runMain = Λa.λJhc.IO.74_main∷Jhc.Prim.IO a.λJhc.IO.75_w∷Jhc.Prim.World__. case Jhc.IO.74_main Jhc.IO.75_w of (# v2∷Jhc.Prim.World__, v3∷a #) → v2; ... .... ...

1 0

Re: [jhc] JHC's internal format conflicting with ARM instruction set?
by John Meacham 07 Jan '11

07 Jan '11

Actually, The only functions that need tag bits are the evaluation functions and they are only called from the eval function, so all we need to do is force them all to use the same instruction set then we can just set the correct lower bits in eval. If gcc can't be persuaded to do this, then a simple assembly stub would work. On Jan 6, 2011 9:12 PM, "John Meacham" <john(a)repetae.net> wrote:

2 1

JHC's internal format conflicting with ARM instruction set?
by Simon Broadhead 07 Jan '11

07 Jan '11

Hello, I've spent a day and half playing with JHC and setting it up to cross compile to ARM and link with an iPhone application. I'm using the Apple iPhone SDK 4.2 toolchain with debug flags enabled. I exported a simple function from Haskell and everything worked fine, but when I tried a function which requires lazy evaluation, unpredictable behaviour including crashing began to occur. When running in the simulator (i.e., as x86 code) everything is fine, but on the actual ARM device, it crashes as soon as a lazy thunk has to be evaluated -- this happens even if I just generate C code and include it in my Xcode project with the appropriate compiler flags. After a few hours of debugging, I believe the problem comes from a property of the ARM instruction set that conflicts with the way pointers are stored internally by JHC. The problem seems to arise because the instruction that is being generated by GCC for calling function pointers (BLX -- Branch with link and exchange instruction set) reads the LSB of the function pointer and, depending on if it is 0 or 1, switches between two different instruction sets: ARM or Thumb. GCC's code generation is smart enough to determine if a function is compiled using ARM or Thumb and so the address returned by '&function' can have either a 0 or 1 in its lowest bit. When the BLX instruction is called, the bottom two bits are ignored and the correct location is jumped to, but if the lowest bit is incorrect, the instruction set changes and the instruction it finds there will be interpreted as garbage. Since JHC uses the low-order bits of pointers, including function pointers, to store flags, and then does its own truncation before the function pointer is called (LSB always 0), undefined behaviour occurs. (A minor side effect of this behaviour is that the TO_SPTR_C macro, which adds flags to a pointer through pointer arithmetic, doesn't work and has to be changed to use the | operator in order for it to generate a valid pointer.) I have yet to find any combination of compiler flags that will allow this to work on ARM, if any exist. Since the behaviour is defined at the instruction level, any compiler-level fixes would probably have to generate a significant amount of extra code (and overhead) to keep it working in any case. Regards, Simon Broadhead

2 1

Problem with building darcs jhc libs
by Korcan Hussein 02 Jan '11

02 Jan '11

Hi, I can build jhc compiler from source as long as I add "-hide-package container-0.4.0.0" and using "-package containers-0.3.0.0" in the Makefile.am I'm just having a problem trying to build the jhc libraries I get this error message: Typechecking... Compiling... Writing Library: flat-foreign-1.0.hl perl utils/build_extlibs.prl lib/ext/containers.cabal Can't locate LWP/Simple.pm in @INC (@INC contains: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl5 /usr/share/perl5 /usr/local/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/local/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl .) at utils/build_extlibs.prl line 6. BEGIN failed--compilation aborted at utils/build_extlibs.prl line 6. make: *** [containers-0.3.0.0.hl] Error 2 Maybe a missing new file from darcs repository?

2 2

foreign ptr bugs
by Korcan Hussein 02 Jan '11

02 Jan '11

Hi I mentioned this briefly in the past before, there is a bug when there are multiple foreign pointers in the same lexical scope obtained from (different) foreign binding functions. The pointer values end up having the same address this typically happens when GCC optimizations are enabled for which most of the time I can make code work correctly by adding -fdebug option to jhc. I've attached some test code which prints out pointer values while trying to blit a loaded image to screen, you'll need to grab my modified version of the SDL Haskell bindings ( darcs get http://patch-tag.com/r/snk_kid/jhc-sdl there is a makefile in jhc folder just make, make install). If you first try building the test code with the command: jhc -p SDL test.hs -o test --optc='-lSDL' and then see the result and output of the program running then try with adding "-fdebug" you should see the difference. Another problem I've been having is erroneous C code generated with the same test code when I set the flag "-fno-global-optimize". I'm using fedora, jhc-0.7.6 The image can be found here: https://github.com/snkkid/LazyFooHaskell/blob/master/lesson01/hello.bmp

2 12