December 2000 - Glasgow-haskell-users

ANNOUNCE: Happy version 1.9
by Simon Marlow 21 Dec '00

21 Dec '00

ANNOUNCING Happy 1.9 - The LALR(1) Parser Generator for Haskell ----------------------------------------------------------------- I'm pleased to announce version 1.9 of Happy, the parser generator system for Haskell. Changes in this version, relative to version 1.8 (the previous full release): * A grammar may now contain several entry points, allowing several parsers to share parts of the grammar. * Some bugfixes. Happy is available in source form, which can be compiled with GHC version 4.xx (4.08.1 recommended), and we also provide binaries for some architectures. The Happy homepage with links to the various distributions lives at: http://www.haskell.org/happy/ Please send any bug reports and comments to simonmar(a)microsoft.com.

3 2

RE: The Set type
by Simon Marlow 21 Dec '00

21 Dec '00

George Russell wrote: > A minor quibble I know, but every time I use sets I want to > add/subtract single elements > to/from them. There is no function provided for doing this, > so instead you have to do > union/delete with a singleton set constructed from the > element. Done. Set now has addToSet :: Ord a => Set a -> a -> Set a delFromSet :: Ord a => Set a -> a -> Set a The names and argument order were chosen to be consistent with FiniteMap, so don't complain :-) Cheers, Simon

1 0

RE: C stack
by Simon Marlow 18 Dec '00

18 Dec '00

> Simon Marlow wrote: > > > > I don't forsee any problems with the C stack - the stack > pointer stays > > static during execution of Haskell code, and only moves > when we do a C > > call or return to the RTS. > > But how do I get the address of the bottom of the stack ? It > seems I can > define a C main so I can get the bottom of the stack, but how > do I make > it call Haskell's main to start the application ? Well, you could "foreign export" your top-level Haskell function and just call it from C. Check out ghc/includes/RtsAPI.c for the API (you need to call startupHaskell() first and shutdownHaskell() afterward). Sadly we haven't documented this stuff very well. Cheers, Simon

1 0

Re: Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
by Reuben Thomas 18 Dec '00

18 Dec '00

> From: Jeremy Shute [mailto:shutej@rpi.edu] > I've been perusing the documentation looking for what I've done wrong... Nothing; the docs aren't quite up-to-date. > 7. Confirmed that these files exist nowhere on the partition. Messed > around some more to no avail, came across static flag and tried that: We don't supply the DLLs any more, because they subtly and rarely don't work for reasons I don't fully understand (though I've spent a long time trying to). If you really want them (why?) you'll have to build them. -- http://sc3d.org/rrt/ | maximiste, n. pessimiste

1 0

Having to use -static flag under Win32 with 4.08 & Cygwin 1.1.6
by Jeremy Shute 16 Dec '00

16 Dec '00

Hi, I've been perusing the documentation looking for what I've done wrong... 1. I got the latest versions of both Cygwin and GHC. 2. I installed Cygwin on a clean partition, F: 3. I installed GHC in /usr/share/ghc/ (on F:, of course) 4. I copied the Perl binary over to /bin, and pointed the bang in the ghc script to the location of the binary (I found this a necessary step). 5. I got a little test program from the web: {--------------------------------------} module Main where main = putStrLn "Hello, World!" {--------------------------------------} 6. Tried to compile said program: $ ghc main.hs Output file not specified, defaulting to "main.exe" gcc: F:/usr/share/ghc/lib/Main.dll_o: No such file or directory gcc: F:/usr/share/ghc/lib/PrelMain.dll_o: No such file or directory 7. Confirmed that these files exist nowhere on the partition. Messed around some more to no avail, came across static flag and tried that: $ rm Main.hi main.o $ ghc -static main.hs Output file not specified, defaulting to "main.exe" $ ./main.exe Hello, World! 8. Think I'm onto something so look around for an additional installation step I perhaps did not take, such as building libraries from source shipped with the distro. Nope, can't find any. I can't imagine why that would even be necessary, to support Win32 on Alphas maybe? So alas, here I sit frustrated, waiting for comp.lang.functional, and I figured I'd try you guys. Has anyone else had this problem? If not, perhaps you still have an idea of what's going on? This would be much appreciated... Jeremy Shute

1 0

RE: C stack
by Simon Marlow 15 Dec '00

15 Dec '00

> Hi, > > I'm trying to write an interface for a C library that > uses a Boehm type garbage collector. So, I need to get > the address of the bottom of the C stack. In a C > application this would look something like: > main() > { > int bottomOfStack; > } > Where "&bottomOfStack" would be the thing I need. So, > I'd want some function like: > bottomOfStack :: IO Addr > > Would it be possible at all to make an interface to > a C library that uses Boehm's garbage collection ? > What Boehm's algorithm does is traverse the C stack > at each garbage collect marking all accessible > nodes and then sweeping all unmarked nodes. Would > this cause problems with the C code generated by > ghc ? I don't forsee any problems with the C stack - the stack pointer stays static during execution of Haskell code, and only moves when we do a C call or return to the RTS. Don't forget to tell the GC to traverse the Haskell heap too - GHC keeps this in mmapped address space. See fptools/ghc/rts/MBlock.c for the details. Cheers, Simon

2 1

RE: Fun with GHC's optimiser
by Simon Peyton-Jones 15 Dec '00

15 Dec '00

PArrays.$w$snewPArray = \ ww :: PrelGHC.Int# w :: PrelBase.Int -> case PrelGHC.newIntArray# @ PrelGHC.RealWorld ww PrelGHC.realWorld# of wild { (# s2#, mba# #) -> let { eta :: PrelBase.Int __A 0 __C eta = PrelBase.$wI# ww } in case PrelGHC.-# ww 1 of sat { __DEFAULT -> case PrelGHC.># 0 sat of wild1 { PrelBase.True -> PArrays.$wPArray @ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#); PrelBase.False -> case w of w1 { PrelBase.I# ww1 -> case PrelGHC.writeIntArray# @ PrelGHC.RealWorld mba# 0 ww1 s2# of s2#1 { __DEFAULT -> case PrelGHC.-# ww 1 of wild2 { 0 -> PArrays.$wPArray @ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#); __DEFAULT -> let { a4 :: (PArrays.PArray PrelBase.Int) __A 0 __C a4 = PArrays.$wPArray @ PrelBase.Int eta (__coerce PrelGHC.ByteArray# mba#) } in __letrec { $wgo :: (PrelGHC.Int# -> PrelGHC.State# PrelGHC.RealWorld -> (PrelGHC.State# PrelGHC.RealWorld, PArrays.PArray PrelBase.Int)) __A 2 __C $wgo = \ w2 :: PrelGHC.Int# w3 :: (PrelGHC.State# PrelGHC.RealWorld) -> case PrelGHC.writeIntArray# @ PrelGHC.RealWorld mba# w2 ww1 w3 of s2#2 { __DEFAULT -> case PrelGHC.-# ww 1 of sat1 { __DEFAULT -> case PrelGHC.==# w2 sat1 of wild11 { PrelBase.True -> (# s2#2, a4 #); PrelBase.False -> case PrelGHC.+# w2 1 of sat2 { __DEFAULT -> $wgo sat2 s2#2 } } } }; } in case $wgo 1 s2#1 of wild3 { (# ds, r #) -> r } } } } } } } | However, we came across one problem (read, lack of | optimisation on GHC's part), which leads to tedious | duplication of a lot of code in our array library. | Basically, GHC does not recognise for tail recursive | functions when certain arguments (accumulators maintained in | a loop) can be unboxed. This leads to massive overheads in | our code. Currently, we circumvent the inefficiency by | having manually specialised versions of the loops for | different accumulator types and using RULES to select them | where appropriate (based on the type information). I will | send you some example code illustrating the problem soon. Yes please. Meanwhile, in the head, if you specify -O2 you'll get better code for some of your loops, namely the ones that repeatedly evaluate a free variable every time round the loop. The loop is duplicated and everything is nice. Here's a tiny example: g :: Int -> Int g x = let h 0 = 0 h y = if x==0 then y else h (y+1) in h 88 This now compiles to: LC.g = \ x :: PrelBase.Int -> case x of wild { PrelBase.I# x1 -> case x1 of wild1 { 0 -> PrelBase.$wI# 88; __DEFAULT -> __letrec { $wh :: (PrelGHC.Int# -> PrelBase.Int) __A 1 __C $wh = \ ww :: PrelGHC.Int# -> case ww of wild2 { 0 -> LC.lit; __DEFAULT -> case PrelGHC.+# wild2 1 of sat { __DEFAULT -> $wh sat } }; } in $wh 89 } } You mentioned something like this before. The amount of code duplication is controlled by -fliberate-case-threshold20 (say) The default is set pretty low. And it all only happens with -O2. All in the HEAD. The pass is call simplCore/LiberateCase. Simon

2 2

C stack
by Jan Kort 14 Dec '00

14 Dec '00

Hi, I'm trying to write an interface for a C library that uses a Boehm type garbage collector. So, I need to get the address of the bottom of the C stack. In a C application this would look something like: main() { int bottomOfStack; } Where "&bottomOfStack" would be the thing I need. So, I'd want some function like: bottomOfStack :: IO Addr Would it be possible at all to make an interface to a C library that uses Boehm's garbage collection ? What Boehm's algorithm does is traverse the C stack at each garbage collect marking all accessible nodes and then sweeping all unmarked nodes. Would this cause problems with the C code generated by ghc ? Jan

1 0

Transitive inlining
by Manuel M. T. Chakravarty 11 Dec '00

11 Dec '00

In the context of the array library, we stumbled over another problem. Does GHC transitive inlining across modules? Let's say, we have the following scenario: module B (foo) where {-# INLINE foo #-} foo .. = ...bar... {-# INLINE bar #-} bar .. = ... module L (baz) where import B {#- INLINE baz #-} baz .. = ...B.foo... module Main where import L main .. = ...L.baz... GHC in this case inlines the whole expression "...B.foo..." in `Main', but will it inline the right hand side of `B.bar' in `Main' (or even of `B.foo')? If the INLINE pragma is transitive across modules boundaries, one would hope so. It seems that GHC is not (always?) doing this inlining, which already for a very simple benchmark costs us a factor of 5 runtime! (With inlining - enforced by copying definitions manually into `Main' - the code produced by GHC is actually a little bit faster than the code for the corresponding C program). Cheers, Manuel PS: I had problems building GHCi and it seems as if my message to cvs-ghc(a)haskell.org doesn't get through somehow...

2 1

RE: Beginners profiling question
by Simon Marlow 11 Dec '00

11 Dec '00

> Your picture shows that sat uses 12% of the time, and main > uses 99% which is > fine because it inherites all time usage. But main really > only calls sat, like > so: > > main = do > ~[rnastr] <- getArgs > print (sat (str2inp rnastr (0::Int))) > > str2inp is just a small data conversion routines for sat. So where > does all the time go? Probably in "print". Yes, the Prelude isn't compiled with -auto-all (or even -auto) by default. We'll probably start doing this when the better profile viewers come on-line. Cheers, Simon

1 0