December 2003 - Glasgow-haskell-users

RE: import modules from a different directory
by Simon Marlow 11 Dec '03

11 Dec '03

> Anybody has the experience of importing a module from a different > directory?In my code, i need to import a module that is not > in the current > directory. How can I do that in GHC? GHC-specific questions are best asked on glasgow-haskell-users(a)haskell.org (where I've sent this followup). You'll find the -i option to GHC will do what you want. Documentation is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilatio… Cheers, Simon

1 0

Making GHCi object files on MacOS
by George Russell 10 Dec '03

10 Dec '03

Section 4.10.3 of the GHC manual tells me to use ld -r --whole-archive to convert a .a file into a .o file suitable for GHCi. However these options only work for GNU ld, which doesn't seem to be available on MacOS (uname -srv gives me "Darwin 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC"). Specifically, I tried compiling the GNU binutils but got a message from its ./configure telling me that this wouldn't work for the ld directory. I presume there must be some way of producing GHCi object files on MacOS, but how is it done? Thanks

3 5

Re: incompatible signatur syntax within instance definition
by Christian Maeder 10 Dec '03

10 Dec '03

Fergus Henderson wrote: > I think the issue here is that in ghc (with -fglasgow-exts), > the "a" here refers to the same type variable "a" in the > top of the instance declaration, which has already been > constained, and cannot be constrained again. Is that a bug or a feature? > With Haskell 98, it is a fresh type variable, for > which the constraint is necessary. Ok, if I view the local function as a new/independent function, I accept to add the Constraint, but that should be acceptable for ghc -fglasgow-exts as well (as is for hugs with extensions). > Try renaming the type variable as "b" in the inner declaration: > the following should work both with and without -fglasgow-exts. > > showsl :: Show b => List b -> ShowS Yes, this works, but I never thought that the choice of "a" or "b" would matter. Christian >>>instance Show a => Show (List a) where >>> showsPrec _ Nil = showString "[]" >>> showsPrec _ l = >>> showString "[" . showsl l . showString "]" >>> where -- showsl :: List a -> ShowS -- for ghc >>> -- showsl :: Show a => List a -> ShowS -- for hugs

3 5

Re: ghc fails "hello world" on ppc
by frederik＠ugcs.caltech.edu 10 Dec '03

10 Dec '03

I forgot to say that the version is 6.0.1. So... can anyone else reproduce this? Is there a stable version of the compiler which I should be using instead? Is there anything I can do to help fix this bug? frederik(a)ugcs.caltech.edu writes: > $ uname -a > Linux fly 2.4.19-quiet #10 Tue Jan 12 17:02:50 PST 1904 ppc GNU/Linux > $ cat > test.hs > main = > do > putStr "hello\n" > putStr "world\n" > $ ghc --make test.hs && ./a.out > Chasing modules from: test.hs > Compiling Main ( test.hs, ./test.o ) > Linking ... > world > world > > On my i386 machine it works correctly: > > $ ghc --make test.hs && ./a.out > Chasing modules from: test.hs > Compiling Main ( test.hs, ./test.o ) > Linking ... > hello > world > > Various permutations of the original program produce the same result > on the ppc: > ---------------------------------------------------------------- > import System.IO > main = > do > hSetBuffering stdout NoBuffering > putStr "hello\n" > putStr "world\n" > ---------------------------------------------------------------- > import System.IO > main = > do > hSetBuffering stdout NoBuffering > putStrLn "hello" > putStrLn "world" > ---------------------------------------------------------------- > main = > do > putStrLn "hello" > putStrLn "world" > ---------------------------------------------------------------- > etc., except that anything with putStrLn prints > hello > hello > instead of > world > world > > > TIA. > > Frederik Eaton

1 0

RE: replacement of main
by Simon Marlow 09 Dec '03

09 Dec '03

> > > 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' > > > ---- > > > > Which version of GHC is it that you're using? > > 6.0.1 I can't manage to get this error by doing the obvious things. Could you try to cut down the example (to one Haskell module module preferably) and send us the code and the complete command line to reproduce the error? Cheers, Simon

1 0

RE: replacement of main
by Simon Marlow 08 Dec '03

08 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' > ---- Which version of GHC is it that you're using? Cheers, Simon

2 1

RE: Template Haskell and the command line
by Simon Marlow 08 Dec '03

08 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! What's wrong with using environment variables, with System.Envorinment.getEnv? To use your example, you would write: $ SIMON=MARLOW foo Cheers, Simon

1 0

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