- Glasgow-haskell-users

RE: ghc warnings messed up in 6.01
by Simon Marlow 08 Dec '03

08 Dec '03

> Simon seems to have agreed that The Right Thing is to treat bindings > with names beginning with an underscore as if they are used w.r.t. to > the bindings they use (they're already treated as used w.r.t. warnings > for themselves.) With this enhancement (and the other warning fixes > apparently already in HEAD), you should be able to change "ds" to > "_ds" and get no warnings. > > BTW (here's the real point of my message :-)), is this enchancement > planned? For when? Thanks. It won't be in 6.2, but hopefully in 6.4. Cheers, Simon

1 0

RE: Runtime comparison: C++, Java & GHC
by Simon Marlow 08 Dec '03

08 Dec '03

> the runtime for a set of 100 tests with different inputs where: > 1. 751 ms > 2. 932 ms (factor 1.24) > 3. 3074 ms (factor 4.09) I think we ought to be able to get that down further. Could you post the code again? It probably should go in our benchmark suite too. Cheers, Simon

1 0

ghc warnings messed up in 6.01
by John Meacham 07 Dec '03

07 Dec '03

has anyone else noticed that the warnings generated by ghc appear to have become quite incorrect in many cases? in particular, the 'defined but not used' warning is generated spuriously a lot. almost as if it is being checked after dead code elimination and desugaring of some sort.. here is an example which touches all the reproducable bugs I have found. > module Main(main) where > import List(nub) > import Monad() > > as = repeat 'a' > bs = repeat 'b' > ds = nub as > > cs = [(a,b) | a <- as | b <- bs] > > main = print $ take 10 cs ;ghc -W -fglasgow-exts Foo.hs Foo.hs:1: Warning: Module `List' is imported, but nothing from it is used (except perhaps instances visible in `List') Foo.hs:1: Warning: Module `Monad' is imported, but nothing from it is used (except perhaps instances visible in `Monad') Foo.hs:7: Warning: Defined but not used: ds Foo.hs:9: Warning: Defined but not used: b Foo.hs:9: Warning: Defined but not used: a notice: 1) it claims nothing is used by List, when 'nub' definatly is being used. (technically true, since ds is not used, but this warning is more confusing than anything. my first inclination is to delete the import line, causing the program to fail to compile, the only fix seems to be to track down the root by hand) 2) it claims Monad is unused, when I specifically imported it with () meaning I don't want any names from it. (i.e., I just want instances) 3) defined but not used 'ds': yay! the only valid warning. 4,5) variables bound in parallel list comprehensions always seem to generate warnings. AFAIK, none of these were problems in earlier versions of ghc, they are quite anoying as they obscure valid warnings. my guess is some desugarings and warning passes were accidentally switched around.. problem 1 is particularly bad, since a single unused toplevel could cascade to generating a ton of warnings, all of which must be sorted through to find the actual cause. the others are just anoying as there doesn't seem to be a workaround short of disabling warnings. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

3 2

replacement of main
by mahogny＠sirius.areta.org 06 Dec '03

06 Dec '03

ok, I guess this is not something you do every day; I am making a language binding for the library Allegro which has some weird things going on. I need to make a main() in C. so I followed the manual, I export my non-main haskell entrypoint and call it from the C main which basically is copy-paste from the docs. when I compile everything > ghc Halleg.hs Game.hs stub.c -L....(additional paths for allegro)... -lalleg(a few libs needed) -no-hs-main -o game I get this cryptic error: ---- tcLookup: 'main' is not in scope In the first argument of 'GHC.TopHandler.runIO', namely 'main' When checking the type of 'main' ---- why? it seems GHC is ignoring my -no-hs-main and still messing with it. this is *bad* because what allegro does is to in a weird way rename main to something platform specific (this is to avoid having a console in windows, I think it's doing something under unix too) is there an easy fix to this? any help appreciated

1 0

.hi-boot abuse
by George Brewster 06 Dec '03

06 Dec '03

Hi, I have a question which came up as a result of some attempts to enforce seperate compilation. Suppose we have two modules as follows: ------ A.hs -------- module A (AbstractType) where data AbstractType = it's hidden implementation f :: AbstractType -> String f _ = "foo" g :: AbstractType g = something ------ B.hs --------- module B where import A s = f g Now, I want to be able to Compile A, Compile B, change the implementation of AbstractType in A, recompile A, and then not have to recompile B. Unfortunately, this doesn't seem to happen in GHC 6.0.1, as the representation of AbstractType is placed in A.hi, so when the representation changes, it forces a recompilation of B. In order to get seperate compilation, we tried abusing the .hi-boot mechanism by writing A.hi-boot and changing the "import A" in B.hs to "import {-# SOURCE #-} A": ------- A.hi-boot ------- module A where data AbstractType f :: AbstractType -> GHC.Base.String g :: AbstractType This, scarily enough, accomplishes what we want (forcing AbstractType to be very abstract, so changes to it don't require recompilation of B), but could lead to some evil breakage if A.hi-boot doesn't match A. At first glance, it seems like it wouldn't be too hard to have the compiler do a consistency check between A.hs and A.hi-boot when A is compiled, which would make this safe (assuming that compiling B using only A.hi-boot is safe if A.hi-boot is consistent with A...). Thus, it seems like the hi-boot mechanism could be extended to allow programmers the option of manually writing interfaces to reduce compile dependencies between modules. Certainly this would come at some cost in performance, but it seems like a useful tradeoff to allow. Is this reasonable? -George Brewster

1 0

Runtime comparison: C++, Java & GHC
by Andreas.Schroeder＠gillardon.de 03 Dec '03

03 Dec '03

Hi all, i did some postings around the end of october about the comparison of the three named language. Well, now (after some forced breaks for other things to do & after overcoming my missing C++ skills) i have made a new comparison based on further financial calculations. More precisely about refunding loans (that's how banks calculate how much money they can earn with certitude if you take up a loan to some conditions). In short, the results are the following on test system (Pentium 3, 700 Mhz, 384 MB ram, Win2k). I tested: 1. cygwin 1.5.5-1 c++ with following flags: -O3 -ffast-math -foptimize-register-move -march=pentium3 -mfpmath=sse 2. Java SDK 1.4.2_01 server VM 3. ghc 6.0.1 with following flags: -O2 -fglasgow-exts -fexcess-precision -optc-march=pentium3 -optc-mfpmath=sse the runtime for a set of 100 tests with different inputs where: 1. 751 ms 2. 932 ms (factor 1.24) 3. 3074 ms (factor 4.09) most interesting that haskell/ghc did better this time than last time, where i compared simpler calculations - or let's say more ``numerical'' calculations that wheren't based on much data structures. I will be off the office for a week, then i will test the .Net 2003 C++ compiler. Regarding these results, the usage of Haskell is quite promising. Did i allready say that i took about 10 times longer to write the (&"%&"$%&!!) C++ code than i took for Haskell code? Regards, Andreas Schroeder

1 0

Template Haskell and the command line
by George Russell 02 Dec '03

02 Dec '03

Template Haskell is frightfully good and we want to get rid of cpp and use it instead, but there's one tiny problem, namely that for cpp it is possible to define variables on the command line (-DSIMON=MARLOW and so on) while with Template Haskell it doesn't seem to be. Could there be some kind of dictionary, like the cpp environment variables, which the Template Haskell code has access to? One obvious way would be to accept the -D/-U arguments, and provide Haskell functions which look at them. Of course one /could/ presumably use System.getArgs and analyse the arguments to ghc oneself, but that would mean making guesses about the current GHC syntax. In the meantime we shall still replace cpp with Template Haskell, but find another way. Thanks for Template Haskell!

1 0

Foreign Function Interface (FFI)
by Rafael Martinez Torres 28 Nov '03

28 Nov '03

HI: Reading Haskell 98 FFI report, one question arised: Imported and declared a foreign function , via foreign import ccall foo:: IO(CInt) Is it guaranteed to be executed in atomic way ? I mean , should it block the whole STG system ? Idea: To implement a monitor , in a "external context" , and threads around him to access it, bypassing the Mvar paramter-pass among them...

2 2

Pestilential behaviour of gcc3.3 on Macs
by George Russell 27 Nov '03

27 Nov '03

Yes I know this is really Apple's fault, but according to http://developer.apple.com/documentation/ReleaseNotes/DeveloperTools/GCC3.h… > The GCC 3.3 preprocessor inserts a new pragma, #pragma GCC set_debug_pwd, as part > of the new Distributed Builds feature. (See below.) This may surprise tools and > scripts that depended on the exact form of preprocessed output from GCC. These > scripts should be rewritten to ignore unrecognized pragmas. Would it be possible for GHC to ignore this line? Otherwise ghc -cpp is going to fall over with gcc3.3 on Macs. Of course in the ideal world I know we should be using Template Haskell.

2 1

RE: Time profiling question.
by Simon Marlow 26 Nov '03

26 Nov '03

> Let me ask this question in the abstract, lest I embarrass myself > publicly with my shoddy code: > > Suppose I find that -p style profiling with -auto-all attributes the > majority of the cost of my program to a single function. > Naturally, I'd > like to refine this somewhat. So I add additional cost centres as > follows: > > f a1 ... an > = e > where > d1 = {-# SCC "d1" #-} e1 > ... > d1 = {-# SCC "dn" #-} e1 > > I find it's still attributing almost all of the cost to the > original CC > (f), so I add another SCC, before the RHS. And it _still_ attributes > the same amount to f, and effectively nothing to the body CC. Sounds like it might be a bug. There are known problems in the attributions of costs in the profiling system, though: in particular some transformations in the simplifier can affect the cost attribution. This might be what's happening, but it would be nice to see an example so we can investigate. Any chance you can boil down your code? Cheers, Simon

1 0