December 2007 - Glasgow-haskell-users

About -Wall option
by Luis Cabellos 05 Dec '07

05 Dec '07

Hi, I have a question, what's the best way to program? - put all the signatures in the Haskell Code? - Only put the type signatures needed to compile (like monomorphism errors or ambiguous signature)? Until now, I prefer the second one, but when I use the -Wall option, there's a lot of complains about type signature. Maybe the type signature is something that not need to be checked as a warning. But if the best practice is to put all the signatures, I found that Cabal generated code need to be fixed, because -Wall complains about it also. -- Thanks, Luis Cabellos,

3 2

Profiling and class methods
by Ravi Nanavati 04 Dec '07

04 Dec '07

One of the smaller nits I noticed when looking at profiles generated by 6.8.1 (using -prof -auto-all) is that class methods show up as cost centers named something like "$f5". I can look at the call stack and figure out that $f5 is probably the call to a particular class method in a particular location, but I was wondering what it might take to make that more user-friendly (I'd want to see the class name, method name and the instance being used in some format, ideally). Is that information readily available and it is just a matter of making -auto-all smarter, or is there a reason this would be tricky? Thanks, - Ravi

2 1

GHC generated dll makes Excel crash on exit.
by Olivier Boudry 04 Dec '07

04 Dec '07

Hi all, I need to call an Haskell module from Excel and as an exercise I started to play with the example given in GHC documentation: http://www.haskell.org/ghc/dist/current/docs/users_guide/win32-dlls.html I could build the DLL without problem but encountered a problem when using it. I created an Excel document using the dll. If I open the Excel document, do something that will trigger a function call in the DLL, then Excel will crash on Exit. On the opposite if I open the same document and changes cells not related to the function the program closes properly. I does not crash directly on the function call but later, just when I close Excel. As it crashes when closing Excel I suspect something is wrong when unloading the dll. I modified the dllMain.c code to handle the DLL_PROCESS_DETACH event but it doesn't solve the problem. } else if (reason == DLL_PROCESS_DETACH) { shutdownHaskell(); return TRUE; } I attached the code to this e-mail. I built the dll this way: ghc -fglasgow-exts -c adder.hs ghc -c dllMain.c ghc -shared -o adder.dll adder.o adder_stub.o dllMain.o Any idea on what could go wrong? Another event to handle? Thanks, Olivier.

3 9

ghc vs ghci: why can't ghci do everything ghc can do?
by Claus Reinke 04 Dec '07

04 Dec '07

1) is there a single place/wiki/ticket that collects all the deficiencies of ghci, compared to ghc? things like: a) which platforms have ghc, but not ghci b) which features are available in ghc, but not in ghci c) does ghci encounter bugs where ghc would succeed d) which of these deficiencies are temporary, which are likely to stay 2) given that ghci is ghc --interactive, why are there any cases of b/c above at all? wouldn't it be possible for ghci to try its stuff, but to fall back to ghc only for those modules which it can't handle from source itself (yet)? - we can do ghc --make; ghci, to get around issues - we can do ghci -fforce-recomp, to get to sources but those two are rather coarse-grained, and require too much manual tweaking to get the effect of creating a ghci session with as many modules from source as possible, and all others from object files. 3) suggestions: a) could we have a :make command in ghci that does a 'ghc --make' while reusing the information from the current session? b) could we have a --prefer-source option for ghci, so that 'ghc --make; ghci --prefer-source' will try to load all modules from source, but will fall back to the existing object files if necessary (instead of failing, as -fforce-recomp does)? c) allow selective switching between source and object files loaded into ghci (:prefer source M,N,..; :prefer object O,P,Q,..). the application i have in mind is trying to use ghci on non-trivial projects, such as darcs, or even ghc itself: - it isn't possible to load all sources into ghci - loading all object files is possible, but prevents use of ghci features such as ':m *Module', ':browse *Module', breakpoints, tags, .. - ghci -fforce-recomp fails because it applies to all modules - there is substantial setup to do before one can call ghc or ghci, so dropping out of a session and trying to figure out dependencies and flags for compiling individual modules by hand isn't practical - there is often a configurable makefile, so that one can use the same setup for calling either 'ghc --make' or 'ghc --interactive'; but, within the latter, one cannot simply switch to full :make or to selective --prefer-source, without losing the setup ideally, ghci would simply work whereever ghc works, and would provide its additional features for as many modules as it can. but in the interim, having 3a and especially 3b would help me a lot. 3c would also be nice, too, but not as urgent as 3b. i find it sad that, currently, there is this gap that doesn't allow me to make full use of ghci's features for larger projects such as darcs or ghc. is hoping for 3b realistic? claus

2 3

Leopard: ghc 6.8.1 and the case of the missing _environ
by Joel Reymont 04 Dec '07

04 Dec '07

Symptoms: You build 6.8.1 from source on Leopard (x86 in my case) and then junior:ghc-6.8.1 joelr$ ghci GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help ghc-6.8.1: /usr/local/lib/ghc-6.8.1/lib/base-3.0.0.0/HSbase-3.0.0.0.o: unknown symbol `_environ' Loading package base ... linking ... ghc-6.8.1: unable to load package `base' Problem: ghc binaries are being stripped upon installation which eliminates _environ, e.g. junior:tmp joelr$ nm x|grep environ 00002ff0 T ___hscore_environ 0004d004 D _environ junior:tmp joelr$ strip x junior:tmp joelr$ nm x|grep environ Solution: Need to make sure install-sh does _not_ use the -s option. Haven't found out where this needs to be done yet. A temporary workaround is to ask Manuel for the pre-built binaries. Thanks, Joel -- http://wagerlabs.com

3 3

RE: fundeps help
by Sittampalam, Ganesh 04 Dec '07

04 Dec '07

> I think that if you use the HEAD, much of > this will work, if you use the type-equality > notation. But you will probably encounter bugs > too. And in so doing, and reporting them, you'll > be doing us a service. I did originally intend to try all this with the HEAD, but one obstacle to this is the lack of recent linux binaries in http://www.haskell.org/ghc/dist/current/dist/ I tried building it myself, but something or another failed, and in general I think keeping up by that route would be a rather high overhead process. Cheers, Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

2 1

Type Families and enhanced constraints (at run-time)
by Jim Burton 03 Dec '07

03 Dec '07

Hi, I hope this is the right place to ask about working with type families...I want to make a library of Set operations that carries proofs at the type level, e.g. to make things like this possible, > insert :: Member e s' T => e -> Set s -> Set s' > union :: Union s t u => Set s -> Set t -> Set u The trouble is designing the Set datatype so it can be used in type constraints *and* in run-time functions....Something similar is of course possible with fun deps, and I knocked something up following the example of Conrad Parker's 'Instant Insanity' but, crucially, that code is 'trapped' in the type system with no populated types. I want term-level/run-time functions with enhanced constraints, such as in the example Manuel posted in haskell-cafe: > data Z > data S a > > data SNat n where > Zero :: SNat Z > Succ :: SNat n -> SNat (S n) > > zero = Zero > one = Succ zero > > type family (:+:) n m :: * > type instance Z :+: m = m > type instance (S n) :+: m = S (n :+: m) > > add :: SNat n -> SNat m -> SNat (n :+: m) > add Zero m = m > add (Succ n) m = Succ (add n m) This seems like "the best of both worlds" -- maybe it could be a general strategy for making for making these enhanced constraints at the term-level? Make a (populated) GADT and parameterise it with a phantom type (perhaps amongst other things). Make a type operator that can be used to express the constraint on the phantom types carried around by the "regular" populated type. When the type operator appears in the codomain of the function it's a compile-time check on the implementation of that function and when in the domain it checks the user at run-time. However, (SNat n) can be put very succinctly because it doesn't need to carry a value around other than the Peano number in the phantom type. What about Sets? In my case the values in the sets are just labels and could well be empty: > data A ; data B ; data C And I also need to express the cons-ness -- I don't think that needs fancy constraints so it can be done with terms, e.g., an underlying sequence such as in the Collects example. Generally I need to work out what needs to be run-time and what compile-time but I think that would follow from getting the combinations of types and terms in the Set abstraction right...could someone give me a pointer with this? Many thanks, Jim

3 6

GHC porting to FreeBSD-amd64 progress report
by wb＠arb-phys.uni-dortmund.de 03 Dec '07

03 Dec '07

In my effort to produce a working FreeBSD-amd64 compiler I made some progress. Now I have a working stage1/ghc-inplace (which is a 32bit executable producing 64bit code). But the compilation of rts fails in file Apply.cmm with the following message: == gmake all -r; in /.amd_mnt/vestein/host/usr/home/wb/ghc-6.8.1/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -H16m -O -optc-O2 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Apply.cmm -o Apply.o In file included from Apply.cmm:13:0: /.amd_mnt/vestein/host/usr/home/wb/ghc-6.8.1/includes/Cmm.h:333:2: error: #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false gmake[1]: *** [Apply.o] Error 1 gmake: *** [stage1] Error 1 This is, of course, because the derived constants SIZEOF_mp_limb_t is wrong. Is there a way to get to a working system from this intermediate stage? I tried to replace the real 32bit ghc in /usr/local/bin/ghc with a ghc-inplace, but this didn't work. Probably I only need to get the correct derived constants in the header files and remake the files depending on them. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key

3 4

win32&ghc: using more than 2gb of memory
by Bulat Ziganshin 03 Dec '07

03 Dec '07

Hello is it possible to use more than 2gb of memory for win32 ghc-compiled programs? does anyone checked this? i've found that the following switch should be added to cmdline: ghc ... -optl --large-address-aware but can't check compiled executable if this question was never considered, here is some possible problems which may arise: http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1