August 2006 - Glasgow-haskell-users

ANNOUNCE: GHC's new support engineer: Ian Lynagh
by Simon Marlow 21 Aug '06

21 Aug '06

We are delighted to announce that GHC now has a full-time support engineer. He is Ian Lynagh (aka Igloo on IRC), and is well known to many of you on the Haskell and GHC mailing lists. He'll be helping with all aspects of GHC, especially release management, bug diagnosis and tracking, documentation, packaging, and supporting other GHC hackers. Welcome Ian! We were absolutely delighted by both the number and quality of the people who applied for the post, and we want to thank them all very much for doing so. We love you all! Andrew Herbert, the lab director of Microsoft Research Cambridge lab director, also deserves a big thank-you, for supporting this post (no strings attached!). It'll make a huge difference. Looking forward to seeing many of you soon, at the GHC Hackathon [1] (25 people registered), and/or at ICFP in Portland. Simon Peyton Jones and Simon Marlow [1] http://hackage.haskell.org/trac/ghc/wiki/Hackathon

1 0

Efficiency of using field labels vs pattern matching
by Brian Hulley 20 Aug '06

20 Aug '06

Hi, I'm wondering if it is more efficient to pattern match against the components of a record instead of using the field functions, though I'd prefer to just use the field functions. For example, if I write: data R = R {_xRef :: !(IORef Int)} foo :: Int -> R -> IO () foo i R{_xRef = xRef} = writeIORef xRef i is the above more efficient than: foo i r = writeIORef (_xRef r) i I know this is probably a bit silly to worry about the overhead of an extra function call etc but I've at the moment got a lot of code using the first version and I think it would look much neater just using field labels but I don't want to modify it if it will be less efficient since speed is quite critical here. Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

3 4

Digraph.lhs broken?
by Joel Reymont 19 Aug '06

19 Aug '06

/usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes - istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename - istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/ specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn - istage1/simplStg -istage1/codeGen -istage1/main -istage1/ profiling -istage1/parser -istage1/cprAnalysis -istage1/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell - threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno- generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -i../compat -ignore-package Cabal -fglasgow-exts -c utils/Digraph.lhs -o stage1/utils/Digraph.o -ohi stage1/utils/ Digraph.hi utils/Digraph.lhs:133:12: Ambiguous occurrence `indices' It could refer to either `GHC.Arr.indices', imported from Array at utils/Digraph.lhs:43:0-11 or `Data.Array.Base.indices', imported from Data.Array.ST at utils/Digraph.lhs:48:0-19 utils/Digraph.lhs:139:18: Ambiguous occurrence `bounds' It could refer to either `GHC.Arr.bounds', imported from Array at utils/Digraph.lhs:43:0-11 or `Data.Array.Base.bounds', imported from Data.Array.ST at utils/Digraph.lhs:48:0-19 -- http://wagerlabs.com/

3 7

can not find prelude module
by Liang Guang 18 Aug '06

18 Aug '06

I originally used Redhat9.0, and the compilation is fine. But now I switched to Fedora 5, the compiler said it can not find prelude module! I used Yum to install the ghc-6.4.2, and it is put to into /usr/lib/ghc-6.4.2. I tried to add the directory to the makefile as : GHC_OPTS = -O2 -prof -auto-all -i../src:/usr/lib/ghc-6.4.2/ I also tried GHC_OPTS = -O2 -prof -auto-all -i../src:/usr/lib/ghc-6.4.2/imports but they didn't work. I am quite confused, isn't it that the base library(like prelude module) should be included in the search path by default? How can I deal with the problem? Thanks! TOm --------------------------------- Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta.

2 1

Re: GHCi hacking
by Ulf Norell 18 Aug '06

18 Aug '06

On Aug 18, 2006, at 1:06 PM, pepe wrote: > If you have gone that far and modified ghci, wouldn't it be easier to > disable the :load command and hardwire the loading of the UserLayer > module ? Ah, but the thing is that the UserLayer is written by the user and so we don't know what it is before-hand. Also, the user should be able to switch between different Layers without destroying the application state. > 1) CAFs (Constant Applicative Form) are essentially top level > bindings. Top level bindings are closures, as anything in ghc, and > they are in suspended state until they are evaluated. When this > happens the closure is updated to store the computed value, and > because of this evaluation effectively happens only once. > > 2) I don't know, but probably you will notice during your experiments > > 3) Probably no. What happens to top level bindings in the interactive > environment? I think that you lose that environment too after load and > some other commands. An option is to identify and disable all these > commands. I don't want to disable the commands, just the clearing of the environment. At the moment I never revert the CAFs so I'm hoping that the environment will be preserved whatever I the user does. / Ulf

1 0

Is there a way to find out the type of a variable inside a function?
by Andrew Wilcox 18 Aug '06

18 Aug '06

I'm learning Haskell, and I've been reading through various source code examples. I find the ":type" commend in GHCi very helpful in finding out what the type of top-level declarations are. However, it only works on top-level declarations (as far as I know). I find myself looking at code like f x = ... where g = ... wondering what f does, and so I try to figure out what the type of g is... and I get lost pretty quickly! :-) Is there a way to find out the type of g? Thanks! Andrew

2 2

New option -a (append) for hasktags
by Martin Grabmueller 16 Aug '06

16 Aug '06

Hello, when using the hasktags program as advertised in the users manual, e.g. find -name \*.\*hs | xargs hasktags the tags file(s) get repeatedly truncated when there are so many files that xargs calls the hasktags program more than once (because otherwise there would be too many command line arguments). I have patched hasktags to accept a new command line option -a --append append to existing CTAGS and/or ETAGS file(s) which makes hasktags to append to existing tags file(s) instead of truncating it. With this patch, it is possible to index the whole darcs tree for ghc (including all libraries) using the following command: find -name \*.\*hs | xargs hasktags -a I will 'darcs send' the resulting patch and hope this patch will be applied. Thanks, Martin

1 0

class declaration in boot file
by Gaal Yahas 15 Aug '06

15 Aug '06

I'm trying to solve a circularity problem with .hs-boot, but am getting the error: "Illegal class declaration in hs-boot file". The offending declaration is: class (Monad m, Functor m, Eq a, Data a, Typeable a) => ICoercible m a | a -> m I've tried with and without the fundeps. Data and Typeable are in scope, and -fglasgow-exts is set. Any ideas on what else I should be doing? -- Gaal Yahas <gaal(a)forum2.org> http://gaal.livejournal.com/

2 4

recursive import
by Serge D. Mechveliani 15 Aug '06

15 Aug '06

Please, discard my previous request for the help with .hs-boot. I seem to get through the .hs-boot matter. We shall see further. Still it looks strange. The compiler reports errors: this and this thing must not be in .hs-boot. As it understands everything, it could take the .hs copy and filter what is needed for .hs-boot. Why the user needs to create .hs-boot by hand? ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

behaviour of {-# NOINLINE #-} in where clauses
by Duncan Coutts 14 Aug '06

14 Aug '06

This doesn't have the effect I expected: loop xs = case blah of One thing -> ... loop The other -> ... realloc ... where {-# NOINLINE realloc #-} realloc = do something loop ... My intention here was that the loop would not contain the code for realloc and that it'd be done as a call at the cmm level. My intention is to take the slow and rarely taken realloc path out of the code for the fast path. It seems the {-# NOINLINE realloc #-} pagma did not have the effect I intended. Looking at the -ddump-simpl and -ddump-cmm, the code for the realloc gets expanded in place in a branch of a case statement. In the cmm code we end up with just what I didn't want: loop_info: if (offset != 4096) goto later; ... ... lots of realloc code taking up space ... in the instruction / trace cache ... later: .. do the fast bits, read a byte, write a byte jump loop_info; Not only does the slow path take up space but it's in the location favoured by the hardware's static branch prediction. Reversing the test doesn't help because either way ghc turns it into: case thing of _DEFAULT -> 4096 -> and from that generates CMM: if (thing != 4096) goto much_later; ... much_later: ... The reason I was looking at this is because I've been trying to figure out why our lazy byte string fusion primitives are much slower than the strict versions. It's improving though, it's now only half the speed rather than a tenth of the speed. :-) The ByteString.Lazy code is an interesting mixture of strict and lazy. We must strictly read/write the chunks but lazily generate/consume the list of chunks. I just discovered that I should have been reading STG all along rather than core from the simplifier or CMM. STG takes out all the type annotations which tend to make things quite verbose. Mind you, seeing the types can be handy too to see if/how things are unboxed. Even so, I kind of wish there were a stage between STG and CMM that showed the imperative model of STG with linear layout, control flow and notes to indicate thunk/closure allocations. I expect most of my problem is that I do not understand the STG evaluation model sufficiently well to see how it maps to basic blocks, jumps/calls etc. Duncan

3 3