December 2003 - Glasgow-haskell-users

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