October 2004 - Glasgow-haskell-users

x86_64: odd success
by John Meacham 14 Oct '04

14 Oct '04

So my AMD64 books have been burning a hole in my bookshelf for so long, I finally went out and got a athlon 64 and installed fedora core 2. much to my dismay, ghc does not seem to work out of the box. I took the following steps. ; yum install gmp.i386 readline.i386 now a rpm -U of the ghc rpms works great. ghci works properly, and ghc seems to almost work when compiling. the expected happens when I try to compile directly. ;ghc Main.hs -o main # ~/tmp/x-03 10:26PM john@momenergy /usr/bin/ld: skipping incompatible /usr/lib/ghc-6.2.1/libHShaskell98.a when searching for -lHShaskell98 /usr/bin/ld: cannot find -lHShaskell98 collect2: ld returned 1 exit status however, what I expected to work, doesn't. ;ghc -optl-m32 -opta-m32 -optc-m32 Main.hs -o main # ~/tmp/x-03 10:36PM john@momenergy 1 compilation IS NOT required /usr/bin/ld: skipping incompatible /usr/lib64/libgmp.so when searching for -lgmp /usr/bin/ld: skipping incompatible /usr/lib64/libgmp.a when searching for -lgmp /usr/bin/ld: cannot find -lgmp collect2: ld returned 1 exit status everything seems to work perfectly however, if I take the gcc command that ghc would have run (gotten via ghc -v) and simply replace -lgmp with /usr/lib/libgmp.so.3 so, any idea what the problem is? in -m32 mode linux seems to get everything else right, but it can't seem to find that gmp without help. Also, it would be nice if ghc automatically passed -m32 when it was in x86_64 mode and wanted to create i386 code, once this happens, (and the gmp thing is worked out) then x86_64 should work perfectly when creating i386 binaries and I can get started on what I really want to do, which is create a native x86_64 ghc :) It would also be quite important for ghc to support a -m32 flag itself, so I can continue to create i386 and x86_64 builds from the same ghc binary. but one problem at a time.. John -- John Meacham - ⑆repetae.net⑆john⑈

1 1

RE: Mutually recursive modules and derived instances of Data
by Simon Peyton-Jones 13 Oct '04

13 Oct '04

| If I have two modules which are mutually recursive; | | module A where | import B | data TA = TA TB deriving (Data, Typeable) | | module B where | import A | data TB = TB TA deriving (Data, Typeable) | | How do I go about writing a hi-boot that will work in GHC? Good question. At the moment, GHC does not let you put instance declarations in hi-boot files, mainly because instances (being anonymous) are a bit weird. Usually this is OK -- just put the instances outside the loop. But if you want to derive the instances (which is Jolly Convenient) you can't do that. At the moment all you can do is write the instances by hand; sorry. (-ddump-deriv will show you the code GHC itself generates, which you can more or less cut and paste) Two fixes suggest themselves 1. Separate 'deriving' from the data type decl, so you can say derive( Data TA, Typeable TA ) anywhere. People sometimes ask for this for other reasons. 2. Allow instances in hi-boot files You might say "both would be useful", but I'd be interested in people's opinions about which of (1) or (2) would be preferable if you could only have one or t'other. Simon

3 2

RE: deriving...
by Simon Peyton-Jones 13 Oct '04

13 Oct '04

(I assume you mean GHC.) Don't look at the compiler, look at the user manual. That describes what's supported. I have no current plans to withdraw any of the current support. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of MR K P SCHUPKE | Sent: 13 October 2004 14:06 | To: glasgow-haskell-users(a)haskell.org | Subject: deriving... | | | What is the situation with deriving? | | Some instances can be derived automatically for both data/newtype (built in)? | | Some instances cen be derived automatically for newtype (any)? | | You used to be able to define functions useing {|+|} and {|*|} (or similar) | that could be derived for both data and newtype. | | What is the current status, which methods are supported, and will be | supported going forward. | | I ask this because looking at the code in the compiler it seems very | difficault to extend. It would be to specify how to derive new instances | once and for all... | | Keean. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

deriving...
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

What is the situation with deriving? Some instances can be derived automatically for both data/newtype (built in)? Some instances cen be derived automatically for newtype (any)? You used to be able to define functions useing {|+|} and {|*|} (or similar) that could be derived for both data and newtype. What is the current status, which methods are supported, and will be supported going forward. I ask this because looking at the code in the compiler it seems very difficault to extend. It would be to specify how to derive new instances once and for all... Keean.

1 0

-ddump-minimal-imports and -hidir / -odir
by Peter Simons 12 Oct '04

12 Oct '04

Hi, is it possible that GHC doesn't process the -hidir and -odir command-line options correctly when -ddump-minimal-imports is given as well? I have had this problem right now and removing the -(hi|o)dir flags fixed it, so I figured I'd better say something. ;-) Peter

1 0

-allow-extension-for-bottom
by Serge D. Mechveliani 12 Oct '04

12 Oct '04

Dear Haskell implementors, Consider the compilation flag -allow-extension-for-bottom which changes the language meaning so that allows to ignore the bottom value. For example, the programs (1) (\ x -> (if p x then foo (g x) else foo (h x)) ) and (2) (\ x -> foo ((if p x then g x else h x)) ) become equivalent, and many program transformations become possible. I suspect that after compiling and running of a program under -allow-extension-for-bottom the user will discover many helpful information about the original program. For example, under -allow-extension-for-bottom it may run 1000 times faster, and then, the user finds out what to change to have a 1000 times speed-up for the original program for the standard Haskell. Thus, in my particular practical example, it is evident to me that it is better to specify (2). But many similar effects are hard to find out without compiling under -allow-extension-for-bottom. Maybe, the compiler could issue the warnings like, say, "Consider factoring `if' in ... This may improve ... " ? Copy, please, the answer to mechvel(a)botik.ru, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: -allow-extension-for-bottom
by Simon Peyton-Jones 12 Oct '04

12 Oct '04

Ah I see. You get earlier results, but the overall computation is unchanged. Hmm. I can't say I'm persuaded. The transformation is unsound in general and, because it makes programs lazier, it'll slow programs down a bit; in exchange there's the possibility of earlier output (which may or may not be visible in the ultimate result). I think you are better off writing the program you want, rather than relying on the compiler to find it for you! Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 11 October 2004 13:32 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: -allow-extension-for-bottom | | First, thanks to the people who correct me about `equivalence', | (I skip the name because the letter was addressed privately). | | Because we do not mean to compile each program to the equivalent | one of | error "bottom" | | | On Mon, Oct 11, 2004 at 12:44:49PM +0100, Simon Peyton-Jones wrote: | > Can you give a small program that runs 1000x faster in one form compared | > with the other? | > | > Currently, if foo is strict, GHC transforms (2) into (1), not the other | > way round. In general, transforming (1) into (2) looks hard, because it | > means finding the common portions of two expressions. | | Anywhay, this looks like an appropriate business for a clever | compliler (under some option). | | > But I'd be | > interested to see cases where you get a lot of performance from such a | > transformations. | > | > Simon | > | | | I my recent practical example, the program with the factored `if' | prints out in 1 second a very useful information on the first | `steps' of a certain proof (the last steps take long), | while the unfactored version holds the whole result until 30 seconds. | But this is on the toy example. In practice, this may be, say, | 100 hours, because the prover is allowed and expected to think long. | The simplified version of the program is | | main = hSetBuffering stdout NoBuffering >> putStr (out "\n") | | out :: String -> String | | out = let valueTakingLong = last [1 .. (10^7)] > 0 | in | if valueTakingLong then ('a' :) . ('b' :) | else ('a' :) . ('b' :) | | The author intended 'a' to appear immediately. | But it appears only after a long time. | | This is hard to control such things in practice, | one has to take effort to write the factored program. | And usually, this is immaterial whether in (if p x) | (p x) may yield bottom. | | I suspect that | (1) the example can be changed so that the full evaluation time | difference will be 1000 times | (somewhat apply `head' to the above `if' expression ...) | | (2) this concerns not only the `if' factoring, this effects the | `bottom' treating in general. | | What do you think of this? | | ----------------- | Serge Mechveliani | mechvel(a)botik.ru | | | | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces(a)haskell.org | > [mailto:glasgow-haskell-users- | > | bounces(a)haskell.org] On Behalf Of Serge D. Mechveliani | > | Sent: 11 October 2004 12:22 | > | To: haskell(a)haskell.org | > | Cc: glasgow-haskell-users(a)haskell.org | > | Subject: -allow-extension-for-bottom | > | | > | Dear Haskell implementors, | > | | > | Consider the compilation flag -allow-extension-for-bottom | > | | > | which changes the language meaning so that allows to ignore | > | the bottom value. For example, the programs | > | | > | (1) (\ x -> (if p x then foo (g x) else foo (h x)) ) | > | and | > | (2) (\ x -> foo ((if p x then g x else h x)) ) | > | | > | become equivalent, and many program transformations become | > | possible. | > | I suspect that after compiling and running of a program under | > | -allow-extension-for-bottom the user will discover many helpful | > | information about the original program. | > | For example, under -allow-extension-for-bottom it may run 1000 | > | times faster, and then, the user finds out what to change to have | > | a 1000 times speed-up for the original program for the standard | > | Haskell. | > | | > | Thus, in my particular practical example, it is evident to me that | > | it is better to specify (2). But many similar effects are hard to | > | find out without compiling under -allow-extension-for-bottom. | > | | > | Maybe, the compiler could issue the warnings like, say, | > | | > | "Consider factoring `if' in ... This may improve ... " | > | ? | > | | > | Copy, please, the answer to mechvel(a)botik.ru, | > | | > | ----------------- | > | Serge Mechveliani | > | mechvel(a)botik.ru | > | | > | | > | | > | | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Mutually recursive modules and derived instances of Data
by Simon David Foster 11 Oct '04

11 Oct '04

Hi, If I have two modules which are mutually recursive; ---- module A where data TA = TA String deriving (Data, Typeable) module B where data TB = TB TA deriving (Data, Typeable) ---- How do I got about writing a hi-boot that will work in GHC? The problem is that to do proper XML Schema mapping, each Schema needs to map to a single module (vital so that namespace mapping can occur), and of course Schemas can be mutually recursive. My XML Serializer relies on Data.Generics and thus deriving Data and Typeable to work, so I need to be able to build module structures like this. Is it possible? Thanks, -Si.

1 0

HEAD version hsc2hs malfunction
by Peter Simons 11 Oct '04

11 Oct '04

I have problems with the current HEAD version when compiling my ADNS bindings <http://cryp.to/hsdns/ADNS.hsc>. It appears that ghc has stopped passing the correct search path automatically, because with the new version I had to add an explicit "-I/home/simons/projects/foo" when compiling, or it wouldn't find the _stub.(c|h) files. Once I had that sorted out, I got this: /tmp/ghc12865.hc: In function `s8Ej_ret': /tmp/ghc12865.hc:6355: error: `ADNS_d7gS' undeclared (first use in this function) /tmp/ghc12865.hc:6355: error: (Each undeclared identifier is reported only once /tmp/ghc12865.hc:6355: error: for each function it appears in.) Is this a bug in the compiler? In hsc2hs? My fault? Peter

1 1

RE: -allow-extension-for-bottom
by Simon Peyton-Jones 11 Oct '04

11 Oct '04

Can you give a small program that runs 1000x faster in one form compared with the other? Currently, if foo is strict, GHC transforms (2) into (1), not the other way round. In general, transforming (1) into (2) looks hard, because it means finding the common portions of two expressions. But I'd be interested to see cases where you get a lot of performance from such a transformations. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 11 October 2004 12:22 | To: haskell(a)haskell.org | Cc: glasgow-haskell-users(a)haskell.org | Subject: -allow-extension-for-bottom | | Dear Haskell implementors, | | Consider the compilation flag -allow-extension-for-bottom | | which changes the language meaning so that allows to ignore | the bottom value. For example, the programs | | (1) (\ x -> (if p x then foo (g x) else foo (h x)) ) | and | (2) (\ x -> foo ((if p x then g x else h x)) ) | | become equivalent, and many program transformations become | possible. | I suspect that after compiling and running of a program under | -allow-extension-for-bottom the user will discover many helpful | information about the original program. | For example, under -allow-extension-for-bottom it may run 1000 | times faster, and then, the user finds out what to change to have | a 1000 times speed-up for the original program for the standard | Haskell. | | Thus, in my particular practical example, it is evident to me that | it is better to specify (2). But many similar effects are hard to | find out without compiling under -allow-extension-for-bottom. | | Maybe, the compiler could issue the warnings like, say, | | "Consider factoring `if' in ... This may improve ... " | ? | | Copy, please, the answer to mechvel(a)botik.ru, | | ----------------- | Serge Mechveliani | mechvel(a)botik.ru | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2