From ajb at spamcop.net Thu May 1 03:46:20 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu May 1 03:40:44 2008 Subject: Unexpected lack of optimisation In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C4AAA@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0804281413q3bb1b9d1y100560d0592103f9@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE543A2BB@EA-EXMSG-C334.europe.corp.microsoft.com> <404396ef0804290458k739a2b00n26d8201bd7ed7fa6@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE543A6C6@EA-EXMSG-C334.europe.corp.microsoft.com> <20080429203357.7j5knbel4ckc8wos-nwo@fcnzpbc.arg@webmail.spamcop.net> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C4AAA@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080501034620.7li5fwu05cwgwkko-nwo@fcnzpbc.arg@webmail.spamcop.net> G'day all. Quoting Simon Peyton-Jones : > Interesting thought. I think you're describing a possible extension > to the SpecConstr transformation described in "Call pattern > specialisation for Haskell" Without reading the paper, that sounds right to me. > Here 'x' is free in 'g', but x's value is known at g's call sites. > It's not enough just to know "x is a cons" inside g; we must also > have access to z,zs. I would have thought that GHC already optimised this in a separate pass. Doesn't it do some kind of redundant case test elimination? > And it's arguably a bad shortcoming that currently the mere act of > lambda lifting can affect how effective SpecConstr is. Indeed. It also suggests to me that perhaps lambda lifting the pattern matching "retries" might _always_ be a good idea, given that the programmer has no way of controlling inlining for this kind of intermediately-generated function. Cheers, Andrew Bromage From gwright at comcast.net Thu May 1 08:59:12 2008 From: gwright at comcast.net (Gregory Wright) Date: Thu May 1 08:53:37 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <20080426205802.GA17765@matrix.chaos.earth.li> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> Message-ID: <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> On Apr 26, 2008, at 4:58 PM, Ian Lynagh wrote: > On Thu, Apr 24, 2008 at 09:25:26AM -0400, Gregory Wright wrote: >> >> I'll see if I can come up with a patch to the build system that >> avoids >> this. > > I think that this was actually done a while ago: > > [pass -no-user-package-conf to ghc-inplace > Simon Marlow **20080104162840] { > > > Thanks > Ian I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf flag. Wouter, could you check if this fixes the problem you had? bw, Greg From simonpj at microsoft.com Thu May 1 10:21:11 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 1 10:15:37 2008 Subject: instance export decls In-Reply-To: <20080422123244.GA18149@scico.botik.ru> References: <20080422123244.GA18149@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Indeed! I think it'd be good to allow type signatures, including instance signatures, in export lists module Foo( data T (f :: * -> *), instance Functor f => Eq (T f), g :: T f -> T f ) The first step is to evolve a well-worked-out design. I think that'd be a very valuable thing for someone to do. Indeed, I'd really like to see it in Haskell', but it doesn't meet the "tried and tested" criterion. I'm a bit reluctant to invest effort in half-way-house solutions, though. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Serge D. Mechveliani | Sent: 22 April 2008 13:33 | To: glasgow-haskell-users@haskell.org | Subject: instance export decls | | Dear GHC developers, people, | | Do you agree that there exists such a problem for a programmer as | recalling exported instances? | Have Haskell and/or GHC some constructs and tools to help the programmer | to recall the exported instances for a module? | Could GHC support the instance export messages for each module? | | In Haskell-98, the exported instances cannot be named explicitly in the | export list. | Right? | But for easier understanding of a program, it is desirable to allow to | name (in a short form) instances in the export list. | For this reason, I add comments, and write the export like this: | | module Poly | (WithHead(..), WithTail(..), -- classes | Mon(..), Polynomial(..), | lc, polMons | -- , instances | -- for Mon: WithHead, List; | -- for Polynomial: WithHead, Cast Polynomial Mon | ) | The comment of kind "-- , instances ..." | helps to recall which instances are exported, without inspecting all | the (lengthy) module source. | | But when the programmer changes the source, one often forgets to | add/remove the needed comments about instances. | I often forget them (maybe, lazy to recall) when I move pieces of code | between modules. | | So, I suggest the following feature for GHC. | | 1. To allow the export declarations of kind instance {} | (maybe to suggest this for Haskell ?) | 2. If the module under compilation has the word `instance' in its | export list, | then ghc finds the difference set diff for the exported instance | kinds eKinds and the instance kinds nKinds named in the export | list. If not $ null diff, it issues the message: | "Warning: the exported instance kinds and the instance kinds named | in the export differ in the following items: ...". | | Seeing such a message, the user corrects the export list in the source | according to diff. | | For the export list and for their messages, it is probably better to | use a short denotation: the instance kind rather than full instance | declaration. In the instance kind, the part of "(...) =>" is skipped. | | What people think of this suggestion? | | Thank you in advance for your notes and help, | | ----------------- | Serge Mechveliani | mechvel@botik.ru From wss at Cs.Nott.AC.UK Thu May 1 11:50:38 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Thu May 1 11:45:03 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> Message-ID: On 1 May 2008, at 13:59, Gregory Wright wrote: > > I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf > flag. Wouter, could you check if this fixes the problem you had? I tried a "port selfupdate" and "port clean --all ghc", followed by a "port install ghc". I ran into the error below (seems like another file-locking bug). I Bjorn's advice (getting rid of the .ghc directory) - the build went through smoothly. I'm not sure what's going on here. Hope this helps, Wouter ---> Fetching ghc ---> Attempting to fetch ghc-6.8.2-src.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ ---> Attempting to fetch ghc-6.8.2-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ ---> Attempting to fetch ghc-6.8.2-darwin-i386-leopard- bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ ---> Verifying checksum(s) for ghc ---> Extracting ghc ---> Applying patches to ghc ---> Configuring ghc ---> Building ghc with target all ---> Staging ghc into destroot Error: Target org.macports.destroot returned: shell command "cd /opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2 && make install" returned error 2 Command output: Writing new package config file... done. Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/hpc-0.5.0.0 Registering hpc-0.5.0.0... if ifBuildable/ifBuildable template-haskell; then \ cd template-haskell && \ ../installPackage/installPackage '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2/utils/ghc-pkg/ghc- pkg-inplace' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/package.conf' '' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/bin' '/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ ghc-6.8.2' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' ; \ fi Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/template-haskell-2.2.0.0 Registering template-haskell-2.2.0.0... if ifBuildable/ifBuildable readline; then \ cd readline && \ ../installPackage/installPackage '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2/utils/ghc-pkg/ghc- pkg-inplace' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/package.conf' '' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/bin' '/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ ghc-6.8.2' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' ; \ fi Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/readline-1.0.1.0 Registering readline-1.0.1.0... if ifBuildable/ifBuildable Cabal; then \ cd Cabal && \ ../installPackage/installPackage '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.8.2/utils/ghc-pkg/ghc- pkg-inplace' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/package.conf' '' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local' '/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/bin' '/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ ghc-6.8.2' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' '/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/doc/ ghc/libraries/$pkg' ; \ fi Installing: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ ghc-6.8.2/lib/Cabal-1.2.3.0 installPackage: copyFile: resource busy (file is locked) make[1]: *** [install.library.Cabal] Error 1 make: *** [install] Error 1 Error: Status 1 encountered during processing. From mechvel at botik.ru Thu May 1 12:31:40 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu May 1 12:27:48 2008 Subject: instance export decls In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080422123244.GA18149@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080501163140.GA32180@scico.botik.ru> On Thu, May 01, 2008 at 03:21:11PM +0100, Simon Peyton-Jones wrote: > Indeed! I think it'd be good to allow type signatures, including > instance signatures, in export lists > > module Foo( > data T (f :: * -> *), > instance Functor f => Eq (T f), > g :: T f -> T f > ) > > The first step is to evolve a well-worked-out design. I think that'd be > a very valuable thing for someone to do. Indeed, I'd really like to > see it in Haskell', but it doesn't meet the "tried and tested" criterion. Maybe, the GHC developers will first try it in GHC ? > I'm a bit reluctant to invest effort in half-way-house solutions, though. My idea was that the GHC developers may like to convert my suggestion into a carefully designed one and to implement it. > | Behalf Of Serge D. Mechveliani > | Sent: 22 April 2008 13:33 > | To: glasgow-haskell-users@haskell.org > | Subject: instance export decls > | > | Dear GHC developers, people, > | > | Do you agree that there exists such a problem for a programmer as > | recalling exported instances? > | Have Haskell and/or GHC some constructs and tools to help the programmer > | to recall the exported instances for a module? > | Could GHC support the instance export messages for each module? > | > | In Haskell-98, the exported instances cannot be named explicitly in the > | export list. > | Right? > | But for easier understanding of a program, it is desirable to allow to > | name (in a short form) instances in the export list. > | For this reason, I add comments, and write the export like this: > | > | module Poly > | (WithHead(..), WithTail(..), -- classes > | Mon(..), Polynomial(..), > | lc, polMons > | -- , instances > | -- for Mon: WithHead, List; > | -- for Polynomial: WithHead, Cast Polynomial Mon > | ) > | The comment of kind "-- , instances ..." > | helps to recall which instances are exported, without inspecting all > | the (lengthy) module source. > | > | But when the programmer changes the source, one often forgets to > | add/remove the needed comments about instances. > | I often forget them (maybe, lazy to recall) when I move pieces of code > | between modules. > | > | So, I suggest the following feature for GHC. > | > | 1. To allow the export declarations of kind instance {} > | (maybe to suggest this for Haskell ?) > | 2. If the module under compilation has the word `instance' in its > | export list, > | then ghc finds the difference set diff for the exported instance > | kinds eKinds and the instance kinds nKinds named in the export > | list. If not $ null diff, it issues the message: > | "Warning: the exported instance kinds and the instance kinds named > | in the export differ in the following items: ...". > | > | Seeing such a message, the user corrects the export list in the source > | according to diff. > | > | For the export list and for their messages, it is probably better to > | use a short denotation: the instance kind rather than full instance > | declaration. In the instance kind, the part of "(...) =>" is skipped. > | > | What people think of this suggestion? > | > | Thank you in advance for your notes and help, > | > | ----------------- > | Serge Mechveliani > | mechvel@botik.ru > From gwright at comcast.net Fri May 2 08:47:40 2008 From: gwright at comcast.net (Gregory Wright) Date: Fri May 2 08:42:01 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> Message-ID: <62D0E485-E7EC-4321-904E-1A5CD547836B@comcast.net> Hi Wouter, On May 1, 2008, at 11:50 AM, Wouter Swierstra wrote: > > On 1 May 2008, at 13:59, Gregory Wright wrote: >> >> I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf >> flag. Wouter, could you check if this fixes the problem you had? > > I tried a "port selfupdate" and "port clean --all ghc", followed by > a "port install ghc". I ran into the error below (seems like another > file-locking bug). > > I Bjorn's advice (getting rid of the .ghc directory) - the build > went through smoothly. > > I'm not sure what's going on here. Hope this helps, > > Wouter > > ---> Fetching ghc > '/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ > doc/ghc/libraries/$pkg' ; \ > fi > Installing: /opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ > ghc-6.8.2/lib/Cabal-1.2.3.0 > installPackage: copyFile: resource busy (file is locked) > > make[1]: *** [install.library.Cabal] Error 1 > make: *** [install] Error 1 > > Error: Status 1 encountered during processing. Hmmm. If I understand correctly, doing a "port selfupdate" and "port clean --all" gave a locking bug, but after you deleted .ghc, everything worked properly? The locking bug looks like #2134, which is fixed by a patch in Macports' ghc-6.8.2. The patch strictifies a readFile invocation in Cabal, so probably you were still using the out-of-date Cabal installed as a user package. There are two possible causes: either -no-user-package-conf has a bug and doesn't always work right, or you still have the previous revision of the ghc port, before the -no- user-package-conf patch. The latter can happen if there was some problem on the Macports server that delayed indexing the new portfile and serving it as a selfupdate. Can you do a "port installed ghc" and verify that you have revision 3? Best WIshes, Greg From john at repetae.net Fri May 2 18:03:14 2008 From: john at repetae.net (John Meacham) Date: Fri May 2 17:57:34 2008 Subject: instance export decls In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080422123244.GA18149@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20080502220314.GB21252@sliver.repetae.net> On Thu, May 01, 2008 at 03:21:11PM +0100, Simon Peyton-Jones wrote: > Indeed! I think it'd be good to allow type signatures, including > instance signatures, in export lists The problem with instance signatures is that it would give the impression that it would be possible to _not_ export an instance, and it wouldn't make explicit the fact that the instances of all modules it depends on are also exported. John -- John Meacham - ?repetae.net?john? From mechvel at botik.ru Sat May 3 08:33:32 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat May 3 08:29:37 2008 Subject: instance export decls In-Reply-To: <20080502220314.GB21252@sliver.repetae.net> References: <20080422123244.GA18149@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C52C0@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502220314.GB21252@sliver.repetae.net> Message-ID: <20080503123332.GA411@scico.botik.ru> On Fri, May 02, 2008 at 03:03:14PM -0700, John Meacham wrote: > On Thu, May 01, 2008 at 03:21:11PM +0100, Simon Peyton-Jones wrote: > > Indeed! I think it'd be good to allow type signatures, including > > instance signatures, in export lists > > The problem with instance signatures is that it would give the > impression that it would be possible to _not_ export an instance, and it > wouldn't make explicit the fact that the instances of all modules it > depends on are also exported. Yes. Still, listing instances in export makes it possible not to look through all the source module in order to recall the instances defined in this module. ----------- Mechveliani From simonpj at microsoft.com Tue May 6 05:09:17 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 6 05:03:26 2008 Subject: Warnings about unused variables or imports In-Reply-To: References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE554E6BC@EA-EXMSG-C334.europe.corp.microsoft.com> [Moving to GHC users: this thread concerns GHC's warning messages about unused things.] | But there are a few other inconvenient behaviors related only to | warnings, for instance | | module A where | foo x = x | | module B(foo) where | import A | | module C (module A, module B) where | import A | import B | | %> ghc --make C.hs -W: | | C.hs:1:20: Warning: `foo' is exported by `module B' and `module A' | | That's certainly true, but it's the same 'foo'. Just a warning of | course, and I'm not so sure I would argue that it shouldn't be there. | It's the same kind of warning as with any other multiple export of a | symbol I guess. But this pattern is not uncommon (in my code at | least), so the warning is inconvenient. Then again, that particular | warning can be turned off. Here the original intention was to warn about module C( foo, foo ) where... or perhaps module C( module A, foo ) where... but I agree that in the situation you describe the warning is silly. File a ticket for it? | Another, somewhat stranger, behavior: | | module A where | foo x = x | | module B(foo) where | import A | | module C(foo) where | import A | | module D () where | import B | import C | bar x = foo x | | %> ghc --make D.hs -W | | D.hs:2:0: | Warning: Module `B' is imported, but nothing from it is used, | except perhaps instances visible in `B' | To suppress this warning, use: import B() | | D.hs:3:0: | Warning: Module `C' is imported, but nothing from it is used, | except perhaps instances visible in `C' | To suppress this warning, use: import C() | | D.hs:4:0: Warning: Defined but not used: `bar' | | This might be said to be a bug, although it's a bug that would rarely | bite you, since it requires that 'bar' is not exported (or used in | something that is exported). If you export bar, then the warning talks | only of B - which is a rather arbitrary choice. There is something more substantial here. Suppose we have module Foo( g ) where import Bar( f4 ) f1 = f2 f2 = f3 f3 = f4 g = 7 At the moment GHC takes the view that f1,f2,f3,f4, and the import are *all* unused. If we said that just f1 was unused, then you'd delete it and get a new warning about f2; you delete that and get a new warning about f3; and so on. Yet the current behaviour is clearly confusing, even to a clued-up user, let alone a beginner. I'm starting to think that we should just do the obvious thing: report something as unused only if it physically does not occur. Any opinions? Your message also objects to arbitrarily choosing one of the imports as redundant. But if there are two imports import B import C and only one is needed, what would you like GHC to say? It's pretty hard to say "only one of these is needed", because it might be "of these three import declarations, you need 1&2 or 2&3 or 1&3". Simon From duncan.coutts at worc.ox.ac.uk Tue May 6 05:31:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 6 05:24:20 2008 Subject: Warnings about unused variables or imports In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE554E6BC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080430235151.GA2168@soi.city.ac.uk> <20080430235547.GG11012@scytale.galois.com> <20080501161812.GA3529@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C53EC@EA-EXMSG-C334.europe.corp.microsoft.com> <2518b95d0805011428y2414fe3fj6b08efec5dcce914@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE54C5478@EA-EXMSG-C334.europe.corp.microsoft.com> <20080502081024.GA2756@soi.city.ac.uk> <638ABD0A29C8884A91BC5FB5C349B1C32AE554E6BC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <1210066275.30059.309.camel@localhost> On Tue, 2008-05-06 at 10:09 +0100, Simon Peyton-Jones wrote: > There is something more substantial here. Suppose we have > > module Foo( g ) where > import Bar( f4 ) > f1 = f2 > f2 = f3 > f3 = f4 > g = 7 > > At the moment GHC takes the view that f1,f2,f3,f4, and the import are > *all* unused. If we said that just f1 was unused, then you'd delete > it and get a new warning about f2; you delete that and get a new > warning about f3; and so on. > > Yet the current behaviour is clearly confusing, even to a clued-up > user, let alone a beginner. Perhaps to eliminate the confusion we just need to distinguish directly unused and indirectly unused in the warning message: Foo.hs:3:8: Warning: Defined but not used: `f1' Foo.hs:4:8: Warning: Defined but used only by other things that are themselves unused: `f2' Foo.hs:5:8: Warning: Defined but used only by other things that are themselves unused: `f3' (suggestions for better messages text welcome) and similarly for the unused import. Duncan From wss at Cs.Nott.AC.UK Tue May 6 05:38:19 2008 From: wss at Cs.Nott.AC.UK (Wouter Swierstra) Date: Tue May 6 05:33:09 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <62D0E485-E7EC-4321-904E-1A5CD547836B@comcast.net> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <086856DC-BB3C-40B5-BC79-77F35A009179@cs.nott.ac.uk> <20080426205802.GA17765@matrix.chaos.earth.li> <382B4B14-AEA4-4CC6-9620-31E70F898B64@comcast.net> <62D0E485-E7EC-4321-904E-1A5CD547836B@comcast.net> Message-ID: <39F9436B-7935-46F5-8F47-7321EED5F626@Cs.Nott.AC.UK> Hi Greg, On 2 May 2008, at 13:47, Gregory Wright wrote: > Hmmm. If I understand correctly, doing a "port selfupdate" and > "port clean --all" > gave a locking bug, but after you deleted .ghc, everything worked > properly? Yes. I wouldn't worry about it too much. Somehow the problem only pops up if you have an existing ghc installation and a newish Cabal. And even then, there's an easy fix. > Can you do a "port installed ghc" and verify that you have revision 3? The following ports are currently installed: ghc @6.8.2_3+darwin_9_i386 (active) That looks ok to me... Thanks again for your help! Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From hp at rentec.com Tue May 6 15:00:59 2008 From: hp at rentec.com (HP Wei) Date: Tue May 6 14:55:08 2008 Subject: large binary footprint ? Message-ID: machine: Sun Sparc, with SunOS 5.10 ghc version --- 6.8.2 [ solaris-binaries downloaded from ghc site ] The Question: I compiled the code: putStr "Hello World!\n" ghc -o hello -L../lib hello.hs where ../lib contains the libgmp.so The resulting binary code size is 3.9 Mbytes I had the impression that it should be of the order of 500 Kbytes. How can I reach that number ? Thanks HP From bulat.ziganshin at gmail.com Tue May 6 14:41:06 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 6 15:15:05 2008 Subject: large binary footprint ? In-Reply-To: References: Message-ID: <324117814.20080506224106@gmail.com> Hello HP, Tuesday, May 6, 2008, 11:00:59 PM, you wrote: > The resulting binary code size is 3.9 Mbytes > I had the impression that it should be of the order > of 500 Kbytes. How can I reach that number ? strip executable. you can just add -optl-s to ghc cmdline -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From hp at rentec.com Tue May 6 15:26:10 2008 From: hp at rentec.com (HP Wei) Date: Tue May 6 15:20:27 2008 Subject: large binary footprint ? In-Reply-To: <324117814.20080506224106@gmail.com> References: <324117814.20080506224106@gmail.com> Message-ID: hi Bulat, thanks for the speedy reply! I tried the following two ways and got the same result: (1) in the shell, strip hello (2) ghc -optl-s -o hello -L../lib hello.hs They both result in a binary size of ~2.5MBytes, which is about 5 times what I expected (500kbytes). Have I had the 'incorrect impression' of 500kbytes ? Thanks hp On Tue, 6 May 2008, Bulat Ziganshin wrote: > Hello HP, > > Tuesday, May 6, 2008, 11:00:59 PM, you wrote: > > > The resulting binary code size is 3.9 Mbytes > > I had the impression that it should be of the order > > of 500 Kbytes. How can I reach that number ? > > strip executable. you can just add -optl-s to ghc cmdline > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From bulat.ziganshin at gmail.com Tue May 6 15:10:21 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue May 6 15:36:33 2008 Subject: large binary footprint ? In-Reply-To: References: <324117814.20080506224106@gmail.com> Message-ID: <1368172200.20080506231021@gmail.com> Hello HP, Tuesday, May 6, 2008, 11:26:10 PM, you wrote: my haskell-fu ends here :) on win32 platform, hello is about 600k, afair > hi Bulat, thanks for the speedy reply! > I tried the following two ways and got the same result: > (1) in the shell, > strip hello > (2) ghc -optl-s -o hello -L../lib hello.hs > They both result in a binary size of ~2.5MBytes, > which is about 5 times what I expected (500kbytes). > Have I had the 'incorrect impression' of 500kbytes ? > Thanks > hp > On Tue, 6 May 2008, Bulat Ziganshin wrote: >> Hello HP, >> >> Tuesday, May 6, 2008, 11:00:59 PM, you wrote: >> >> > The resulting binary code size is 3.9 Mbytes >> > I had the impression that it should be of the order >> > of 500 Kbytes. How can I reach that number ? >> >> strip executable. you can just add -optl-s to ghc cmdline >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From alexander.fuchs at uni-koblenz.de Wed May 7 10:25:04 2008 From: alexander.fuchs at uni-koblenz.de (Alexander Fuchs) Date: Wed May 7 10:19:11 2008 Subject: Performance: Faster to define a function writing out all arguments? Message-ID: <4821BBC0.5040601@uni-koblenz.de> Hi there, I am trying to write my first serious Haskell program, but have problems understanding 'strange' performance results. It seems to be a ghc specific question, so I am asking here. In a happy parser I have this code 1): %monad { Parsed } { thenP } { returnP } type Parsed = State Env.Env returnP :: a -> Parsed a returnP a = return a thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP x k = x >>= k An alternative was this 2) (yes, redundant in happy): returnP :: a -> Parsed a returnP = return thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP = (>>=) And strangely enough on my machine 1) is faster by a few percent than 2) using ghc 6.8.2 with -O2. A few percent might seem unimportant, but I am currently developing my Haskell style. And I want to write efficient code by default, if that doesn't lead to obfuscation. Now, first I dislike using option 1) because it seems pointlessly verbose. Second, I have no clue why option 2) should be faster. Using ghc -O2 -C I get two code blocks with 1) (appended at the end of this mail), whereas I get nothing with 2. Unfortunately, that doesn't help me as I have no clue what it means. There are also various strictness annotations throughout the code to make parsing less memory hungry (and getting an intuition about what is appropriate here drives me crazy). Random guess: perhaps somehow strictness analysis of ghc benefits from the code in 1)? Or does ghc create specialized versions of return and >>= for State instantiated to Parsed, i.e. State Env.Env? Anyhow, I am puzzled and grateful for any explanations and recommendations about what is going on and when to avoid style 2). Thanks, Alexander C-- code blocks: ------------------------------------------------------- EI_(DarwinziTptpziParser_a106_info); StgWord DarwinziTptpziParser_a106_closure[] = { (W_)&DarwinziTptpziParser_a106_info }; static StgWord s8Ey_info[] = { 0x42U, 0x22U }; IF_(s8Ey_ret) { W_ _c8EL; FB_ Sp[2] = *((P_)(R1.w+7)); _c8EL = *((P_)(R1.w+3)); R1.w = Sp[1]; Sp[1] = _c8EL; Sp=Sp+1; JMP_((W_)&stg_ap_pp_fast); FE_ } StgWord DarwinziTptpziParser_a106_info[] = { 0x30014U, 0x0, 0xfU }; EI_(DarwinziTptpziParser_a106_closure); II_(s8Ey_info); FN_(DarwinziTptpziParser_a106_entry) { FB_ if ((W_)(((W_)Sp - 0x4U) < (W_)SpLim)) goto _c8EO; R1.w = *Sp; Sp[-1] = Sp[2]; *Sp = (W_)&s8Ey_info; Sp=Sp-1; JMP_((W_)&stg_ap_p_fast); _c8EO: R1.w = (W_)&DarwinziTptpziParser_a106_closure; JMP_(stg_gc_fun); FE_ } ------------------------------------------------------- ------------------------------------------------------- II_(r6AT_info); static StgWord r6AT_closure[] = { (W_)&r6AT_info, 0x0, 0x0, 0x0 }; static char c97W_str[] = "Internal Happy error\012"; static StgWord r6AT_info[] = { 0x0, 0x16U }; EI_(base_GHCziBase_unpackCStringzh_info); IF_(r6AT_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c97Z; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c97Z; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; Sp[-3] = (W_)&c97W_str; Sp=Sp-3; JMP_((W_)&base_GHCziBase_unpackCStringzh_info); _c97Z: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } EI_(base_GHCziErr_error_closure); II_(r6AT_closure); StgWord DarwinziTptpziParser_notHappyAtAll_srt[] = { (W_)&base_GHCziErr_error_closure, (W_)&r6AT_closure }; EI_(DarwinziTptpziParser_notHappyAtAll_info); StgWord DarwinziTptpziParser_notHappyAtAll_closure[] = { (W_)&DarwinziTptpziParser_notHappyAtAll_info, 0x0, 0x0, 0x0 }; StgWord DarwinziTptpziParser_notHappyAtAll_info[] = { ((W_)&DarwinziTptpziParser_notHappyAtAll_srt+0), 0x0, 0x30016U }; EI_(base_GHCziErr_error_closure); II_(r6AT_closure); FN_(DarwinziTptpziParser_notHappyAtAll_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c989; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c989; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; R1.w = (W_)&base_GHCziErr_error_closure; Sp[-3] = (W_)&r6AT_closure; Sp=Sp-3; JMP_((W_)&stg_ap_p_fast); _c989: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } ------------------------------------------------------- From hp at rentec.com Wed May 7 17:04:41 2008 From: hp at rentec.com (HP Wei) Date: Wed May 7 16:58:46 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: References: Message-ID: I convinced myself that the ~500kbytes for the 'hello' code is 'correct' in version 6.6.1. [ The exact size on the platform mentioned below is 422k. ] Looks like version 6.8.2 blows up the binary code size significantly --- 3.9Mbytes vs 0.422Mbytes. Is this a known issue with 6.8.2 ? Is it a specific platform dependent issue --- i.e. does it occur on linux machines ?? --hp On Tue, 6 May 2008, HP Wei wrote: > > machine: Sun Sparc, with SunOS 5.10 > ghc version --- 6.8.2 [ solaris-binaries downloaded from ghc site ] > > The Question: > > I compiled the code: putStr "Hello World!\n" > ghc -o hello -L../lib hello.hs > where ../lib contains the libgmp.so > > The resulting binary code size is 3.9 Mbytes > I had the impression that it should be of the order > of 500 Kbytes. How can I reach that number ? > > Thanks > HP > > > From hp at rentec.com Wed May 7 17:20:10 2008 From: hp at rentec.com (HP Wei) Date: Wed May 7 17:14:14 2008 Subject: problem with concurrent port scanner In-Reply-To: References: Message-ID: I cut and paste the code from http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haskell And compiled the resulting portscan.hs with both ghc-6.8.2 and ghc-6.6.1 on a host with Sun-Sparc [SunOS 5.10]. Besides the issue of binary-code-size blow-up with ghc-6.8.2, there is a much more serious problem with codes compiled from both 6.8.2 and 6.6.1. Here is the output of two runs. ------------------------------------------- portscan a_remote_sun_sparc_machine 1 1000 portscan: internal error: getMBlock: mmap: Bad file number (GHC version 6.6.1 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort [ note: same result for 6.8.2 ] ---------------------------------------- portscan a_remote_linux_machine 1 1000 22 ssh 111 sunrpc 513 login 514 shell 631 ------------------------------------------ Anyone knows this problem ? --hp From dons at galois.com Wed May 7 17:20:22 2008 From: dons at galois.com (Don Stewart) Date: Wed May 7 17:14:30 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: References: Message-ID: <20080507212022.GF5108@scytale.galois.com> hp: > > I convinced myself that the ~500kbytes for the > 'hello' code is 'correct' in version 6.6.1. > [ The exact size on the platform mentioned below > is 422k. ] > > Looks like version 6.8.2 blows up the binary code size > significantly --- 3.9Mbytes vs 0.422Mbytes. > > Is this a known issue with 6.8.2 ? > Is it a specific platform dependent issue --- i.e. > does it occur on linux machines ?? That's platform dependent. It means on ghc 6.8.2 wasn't built with split-objs enabled, so it includes a whole bunch of dead code normally stripped out. Consult whoever built the ghc on your platform, to ensure they know how to build with split objects. -- Don From daniel.is.fischer at web.de Wed May 7 17:24:14 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed May 7 17:17:10 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: References: Message-ID: <200805072324.14790.daniel.is.fischer@web.de> Am Mittwoch, 7. Mai 2008 23:04 schrieb HP Wei: > I convinced myself that the ~500kbytes for the > 'hello' code is 'correct' in version 6.6.1. > [ The exact size on the platform mentioned below > is 422k. ] > > Looks like version 6.8.2 blows up the binary code size > significantly --- 3.9Mbytes vs 0.422Mbytes. > > Is this a known issue with 6.8.2 ? > Is it a specific platform dependent issue --- i.e. > does it occur on linux machines ?? > I get 490k for hello without stripping and 274k with stripping on linux. It might be the "-L../lib" option which blows up the binary size. What happens if you just ghc --make hello ? Cheers, Daniel From ndmitchell at gmail.com Thu May 8 04:41:13 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu May 8 04:35:15 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <4821BBC0.5040601@uni-koblenz.de> References: <4821BBC0.5040601@uni-koblenz.de> Message-ID: <404396ef0805080141j6cd8aff4y49e2b3f28a089e6e@mail.gmail.com> Hi > And strangely enough on my machine 1) is faster by a few percent than Consider a few percent to be "noise". It may not really be a faster result, and it may not have anything to do with what you wrote. > A few percent might seem unimportant, but I am > currently developing my Haskell style. And I want to write efficient code by > default, if that doesn't lead to obfuscation. Write clear code by default - GHC can usually make the leap between clear and efficient. You may want to read http://haskell.org/haskellwiki/Performance - but if you are developing your Haskell style I'd not bother yet. Thanks Neil From simonmarhaskell at gmail.com Thu May 8 07:39:14 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu May 8 07:33:26 2008 Subject: problem with concurrent port scanner In-Reply-To: References: Message-ID: <4822E662.5030506@gmail.com> HP Wei wrote: > I cut and paste the code from > http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haskell > > And compiled the resulting portscan.hs > with both ghc-6.8.2 and ghc-6.6.1 > on a host with Sun-Sparc [SunOS 5.10]. > > Besides the issue of binary-code-size blow-up with ghc-6.8.2, > there is a much more serious problem with codes > compiled from both 6.8.2 and 6.6.1. > > Here is the output of two runs. > > ------------------------------------------- > portscan a_remote_sun_sparc_machine 1 1000 > portscan: internal error: getMBlock: mmap: Bad file number > (GHC version 6.6.1 for sparc_sun_solaris2) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Abort Please report the bug as instructed! Cheers, Simon From dons at galois.com Thu May 8 17:40:26 2008 From: dons at galois.com (Don Stewart) Date: Thu May 8 17:34:29 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <4821BBC0.5040601@uni-koblenz.de> References: <4821BBC0.5040601@uni-koblenz.de> Message-ID: <20080508214026.GD3528@scytale.galois.com> alexander.fuchs: > Hi there, > > I am trying to write my first serious Haskell program, but have > problems understanding 'strange' performance results. It seems to be > a ghc specific question, so I am asking here. > > In a happy parser I have this code 1): > > %monad { Parsed } { thenP } { returnP } > > type Parsed = State Env.Env > > returnP :: a -> Parsed a > returnP a = return a > > thenP :: Parsed a -> (a -> Parsed b) -> Parsed b > thenP x k = x >>= k > > > An alternative was this 2) (yes, redundant in happy): > > returnP :: a -> Parsed a > returnP = return > > thenP :: Parsed a -> (a -> Parsed b) -> Parsed b > thenP = (>>=) > Could you submit a minimal, complete grammar file, so we can look at the generated code? -- Don From alexander.fuchs at uni-koblenz.de Mon May 12 11:52:04 2008 From: alexander.fuchs at uni-koblenz.de (Alexander Fuchs) Date: Mon May 12 11:46:07 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <20080508214026.GD3528@scytale.galois.com> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> Message-ID: <482867A4.6020102@uni-koblenz.de> Hi Don. Don Stewart wrote: > alexander.fuchs: >> >> In a happy parser I have this code 1): >> >> %monad { Parsed } { thenP } { returnP } >> >> type Parsed = State Env.Env >> >> returnP :: a -> Parsed a >> returnP a = return a >> >> thenP :: Parsed a -> (a -> Parsed b) -> Parsed b >> thenP x k = x >>= k >> >> >> An alternative was this 2) (yes, redundant in happy): >> >> returnP :: a -> Parsed a >> returnP = return >> >> thenP :: Parsed a -> (a -> Parsed b) -> Parsed b >> thenP = (>>=) >> > > Could you submit a minimal, complete grammar file, so > we can look at the generated code? After reducing and simplifying the grammar file to the minimum for my sample input I can't see any difference in performance anymore. Due to other code changes the difference is almost non-existent anymore even before simplification. I blame laziness for my lack of intuition of what is going on ;-) Anyway, as I am still wondering why ghc creates different code for returnP a = return a returnP = return I put the grammar file online, in case you still want to have a look at it: http://cs.uiowa.edu/~fuchs/DarwinCS/DarwinCS/Darwin/Tptp/Parser.y The complete source (compiles with make opt) is here: http://cs.uiowa.edu/~fuchs/DarwinCS/DarwinCS.tar.gz And I use it on this input: http://cs.uiowa.edu/~fuchs/DarwinCS/SYN854-1.p with the command line: time Darwin/Main +RTS -sstderr -RTS 600 SYN854-1.p Sorry about the noise, Alexander From kili at outback.escape.de Mon May 12 15:57:33 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Mon May 12 15:53:53 2008 Subject: How MD are .hi files? Message-ID: <20080512195733.GA2091@petunia.outback.escape.de> Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. TIA Ciao, Kili ps: if you think this sounds like a complete newbie question, you're right; I've been far too busy hacking on boring stuff like Makefiles, and didn't have time to look at the interesting code (i.e. ghc itself). My knowledge of ghc's internals is at the state of 1998, or even older, I really don't remember ;-) -- Options are good. As long as they are optional. -- Artur Grabowski From dons at galois.com Mon May 12 19:28:47 2008 From: dons at galois.com (Don Stewart) Date: Mon May 12 19:22:39 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <482867A4.6020102@uni-koblenz.de> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> <482867A4.6020102@uni-koblenz.de> Message-ID: <20080512232847.GO8256@scytale.galois.com> alexander.fuchs: > Hi Don. > >Could you submit a minimal, complete grammar file, so > >we can look at the generated code? > > After reducing and simplifying the grammar file to the minimum for my > sample input I can't see any difference in performance anymore. Due to > other code changes the difference is almost non-existent anymore even > before simplification. I blame laziness for my lack of intuition of what > is going on ;-) > > > Anyway, as I am still wondering why ghc creates different code for > returnP a = return a > returnP = return > Ah, now I rember this coming up before. Simon, is this a CAF issue? Or did it trigger the -fno-state-hack case? I've definitely run into the odd other case where point-freeing a bit of code messes with the complexity. -- Don From simonpj at microsoft.com Tue May 13 04:47:47 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 13 04:41:36 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <20080512232847.GO8256@scytale.galois.com> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> <482867A4.6020102@uni-koblenz.de> <20080512232847.GO8256@scytale.galois.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE562B82F@EA-EXMSG-C334.europe.corp.microsoft.com> | > Anyway, as I am still wondering why ghc creates different code for | > returnP a = return a | > returnP = return | > | | Ah, now I rember this coming up before. | | Simon, is this a CAF issue? Or did it trigger the -fno-state-hack case? I'm not sure. A small example would be good. | I've definitely run into the odd other case where point-freeing | a bit of code messes with the complexity. That should not happen -- except for the state-hack. Which is this: Consider f1 :: Char -> IO () f1 = \c. let i = ord c in \s. print i s Here s::State World. Is this equivalent to f2 = \c.\s. print (ord c) s The latter is very much more efficient than 'f1', because it doesn't build an intermediate lambda. This matters a lot in I/O-intensive programs. But if 'f' is called thus: forever (f 'w') then (ord 'w') is computed once for each call of f2, but is shared among all calls to f1. And that can make a big difference too. I have no idea whether this is playing a role in the example you are discussing -- my guess is not, and there may be another performance bug lurking. So eliciting a small demo would be great. Simon From sedillard at gmail.com Tue May 13 19:12:30 2008 From: sedillard at gmail.com (Scott Dillard) Date: Tue May 13 19:06:15 2008 Subject: laziness, memoization and inlining Message-ID: Hi Everybody, I'm experiencing some undesirable performance behavior, I suspect from inlining things that shouldn't be, defeating my memoization attempts. I've been experimenting with purely functional 3D modeling code, so a mesh is (initially) something like > type Mesh = Map (Int,Int) (Int,Int) that is, a function from from an edge to the next edge around the face, where an edge is a pair of Ints (the vertices.) This nice and pure and everything, but its slow to read from. So I have another immutable pointer-based representation > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge } which is something like a half-edge, for those familiar with such things. Its basically a big net made of circular lists that are tied together. I do the knot tying stuff to create this thing, > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int > memoMesh nexts = head $ Map.elems ties > where > ties = Map.mapWithKey (\ij _ -> make ij) nexts > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup ij nexts) The program first loads the model file and creates the Edge-based mesh using the memoMesh function. The result is then captured in the closure for the rendering callback in GLUT. When I compile with -O0 I see the "hello" traces only during the first drawing. Subsequent redraws are fast and output no traces. When I compile with -O1 or -O2, the traces get output on every redraw, and its very slow. I suspect all of the calls which create the mesh are inlined into the rendering callback, effectively rebuilding the mesh on every draw. I've tried littering NOINLINE pragmas all around, to no avail. The main function is something like > main = do > initGlut ... > rawMesh <- loadMeshFile ... > let > mesh = memoMesh rawMesh > otherstuff = ... > display = > draw mesh >> amongOtherThings > displayCallback $= display > glutMainLoop Can someone help me understand what's going on here? Is there a nice solution to this, hopefully a single strategic pragma or something? Scott From dons at galois.com Tue May 13 23:20:11 2008 From: dons at galois.com (Don Stewart) Date: Tue May 13 23:13:58 2008 Subject: laziness, memoization and inlining In-Reply-To: References: Message-ID: <20080514032011.GA9332@scytale.galois.com> sedillard: > Hi Everybody, > > I'm experiencing some undesirable performance behavior, I suspect from > inlining things that shouldn't be, defeating my memoization attempts. > I've been experimenting with purely functional 3D modeling code, so a > mesh is (initially) something like > > > type Mesh = Map (Int,Int) (Int,Int) > > that is, a function from from an edge to the next edge around the > face, where an edge is a pair of Ints (the vertices.) > > This nice and pure and everything, but its slow to read from. So I > have another immutable pointer-based representation > > > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge } > > which is something like a half-edge, for those familiar with such > things. Its basically a big net made of circular lists that are tied > together. I do the knot tying stuff to create this thing, > > > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int > > memoMesh nexts = head $ Map.elems ties > > where > > ties = Map.mapWithKey (\ij _ -> make ij) nexts > > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties > > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup ij nexts) > > The program first loads the model file and creates the Edge-based mesh > using the memoMesh function. The result is then captured in the > closure for the rendering callback in GLUT. When I compile with -O0 I > see the "hello" traces only during the first drawing. Subsequent > redraws are fast and output no traces. When I compile with -O1 or -O2, > the traces get output on every redraw, and its very slow. I suspect > all of the calls which create the mesh are inlined into the rendering > callback, effectively rebuilding the mesh on every draw. Hmm. I wonder if *this* is the no-state-hack at play. Does -fno-state-hack help? > I've tried littering NOINLINE pragmas all around, to no avail. > > The main function is something like > > > main = do > > initGlut ... > > rawMesh <- loadMeshFile ... > > let > > mesh = memoMesh rawMesh > > otherstuff = ... > > display = > > draw mesh >> amongOtherThings > > displayCallback $= display > > glutMainLoop > > Can someone help me understand what's going on here? Is there a nice > solution to this, hopefully a single strategic pragma or something? Is it possible to boil this down to a program that doesn't use GL? -- Don From leledumbo_cool at yahoo.co.id Wed May 14 03:31:41 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Wed May 14 03:25:23 2008 Subject: small and compact ghc distribution Message-ID: <17223701.post@talk.nabble.com> Currently, GHC distribution is VERY BIG (about 410 MB). 2 Things that I noticed which contributed most of this problem are: libraries (about 220 MB) and GCC and friends compiler (including perl, ar, as, ld, etc). I'm a college student and I just want to learn functional programming with Haskell. No need to access libraries other than GHC rtl (or whatever you call it). I already have gcc on my machine, does GHC still need its own? Will there be any small and compact GHC distribution (if someone wants to make it, I'd be very grateful)? -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p17223701.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From bulat.ziganshin at gmail.com Wed May 14 03:45:06 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 14 03:39:13 2008 Subject: small and compact ghc distribution In-Reply-To: <17223701.post@talk.nabble.com> References: <17223701.post@talk.nabble.com> Message-ID: <656997252.20080514114506@gmail.com> Hello leledumbo, Wednesday, May 14, 2008, 11:31:41 AM, you wrote: > I'm a college student and I just want to learn functional programming with > Haskell. No need to access libraries other than GHC rtl (or whatever you > call it). > I already have gcc on my machine, does GHC still need its own? > Will there be any small and compact GHC distribution (if someone wants to > make it, I'd be very grateful)? 1. you can use winhugs - it's more user-friendly. and need only ~10mb in stripped installation 2. you can try to delete all the unneeded libs from ghc distro. in particular, all those *_p* files are just profiling versions - you don't need them 3. i think that ghc should work without gcc at all -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Wed May 14 03:48:00 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed May 14 03:41:45 2008 Subject: laziness, memoization and inlining In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> Scott | I'm experiencing some undesirable performance behavior, I suspect from | inlining things that shouldn't be, defeating my memoization attempts. This is bad, very bad. I think Don is right. I believe the following is happening. In your main program you have do let mesh = memoMesh rawMesh display :: IO () display = draw mesh >> stuff setDisplayCallback display glutMainLoop So the effect is that 'display' is performed many times, by glutMainLoop. Now 'display' is seen by GHC thus: display = \s -> draw mesh s >> stuff The "\s" says "given the state of the world, s, I'll draw the mesh on it". The "state hack" makes GHC think that a "\s" will only ever be called once (which is utterly false in this case), so it can inline mesh=memoMesh rawMesh. Result disaster. I bet you'll be fine if you compile your main module with -fno-state-hack. But I should fix this, somehow. It's coming up too often to justify the hack. Can you make a Trac bug report, and include your message and this one? Thanks for reporting it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Scott Dillard | Sent: 14 May 2008 00:13 | To: glasgow-haskell-users@haskell.org | Subject: laziness, memoization and inlining | | Hi Everybody, | | I'm experiencing some undesirable performance behavior, I suspect from | inlining things that shouldn't be, defeating my memoization attempts. | I've been experimenting with purely functional 3D modeling code, so a | mesh is (initially) something like | | > type Mesh = Map (Int,Int) (Int,Int) | | that is, a function from from an edge to the next edge around the | face, where an edge is a pair of Ints (the vertices.) | | This nice and pure and everything, but its slow to read from. So I | have another immutable pointer-based representation | | > data Edge = Edge { edgeOrg :: Int , edgeSym :: Edge , edgeNext :: Edge } | | which is something like a half-edge, for those familiar with such | things. Its basically a big net made of circular lists that are tied | together. I do the knot tying stuff to create this thing, | | > memoMesh :: Map (Int,Int) (Int,Int) -> Edge Int | > memoMesh nexts = head $ Map.elems ties | > where | > ties = Map.mapWithKey (\ij _ -> make ij) nexts | > lookup ij = trace "hello" $ fromJust $ Map.lookup ij ties | > make ij@(i,j) = Edge i (lookup (j,i)) (lookup . fromJust $ Map.lookup ij nexts) | | The program first loads the model file and creates the Edge-based mesh | using the memoMesh function. The result is then captured in the | closure for the rendering callback in GLUT. When I compile with -O0 I | see the "hello" traces only during the first drawing. Subsequent | redraws are fast and output no traces. When I compile with -O1 or -O2, | the traces get output on every redraw, and its very slow. I suspect | all of the calls which create the mesh are inlined into the rendering | callback, effectively rebuilding the mesh on every draw. | | I've tried littering NOINLINE pragmas all around, to no avail. | | The main function is something like | | > main = do | > initGlut ... | > rawMesh <- loadMeshFile ... | > let | > mesh = memoMesh rawMesh | > otherstuff = ... | > display = | > draw mesh >> amongOtherThings | > displayCallback $= display | > glutMainLoop | | Can someone help me understand what's going on here? Is there a nice | solution to this, hopefully a single strategic pragma or something? | | Scott | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From leledumbo_cool at yahoo.co.id Wed May 14 04:14:35 2008 From: leledumbo_cool at yahoo.co.id (leledumbo) Date: Wed May 14 04:08:20 2008 Subject: small and compact ghc distribution In-Reply-To: <656997252.20080514114506@gmail.com> References: <17223701.post@talk.nabble.com> <656997252.20080514114506@gmail.com> Message-ID: <17225910.post@talk.nabble.com> Bulat Ziganshin-2 wrote: > > 1. you can use winhugs - it's more user-friendly. and need only ~10mb > in stripped installation > That's what I'm using for now, but I need GHC's compilation capability. Bulat Ziganshin-2 wrote: > > 2. you can try to delete all the unneeded libs from ghc distro. in > particular, all those *_p* files are just profiling versions - you > don't need them > OK, I'll try. Bulat Ziganshin-2 wrote: > > 3. i think that ghc should work without gcc at all > Yes, but to scan and delete which files are belong to GHC and which are belong to GCC is quite difficult. That's why I ask for a pre-made (or pre-cleaned) one. -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p17225910.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From marlowsd at gmail.com Wed May 14 06:35:36 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Wed May 14 06:29:23 2008 Subject: How MD are .hi files? In-Reply-To: <20080512195733.GA2091@petunia.outback.escape.de> References: <20080512195733.GA2091@petunia.outback.escape.de> Message-ID: <482AC078.6000802@gmail.com> Matthias Kilian wrote: > Hi, > > for an unregisterised ghc-6.8.2 (or newer), are the .hi files > dependent (except for the 32 vs. 64 bit word size)? I had a quick > look at the stuff in compiler/iface, but the only MD part I found > was that 32/64 bit difference. The word size is probably the only dependency, but there are many reasons that you can't just take the .hc/.hi files generated by an unregisterised build on one machine and expect them to work on another machine. First, you have to watch out for conditional compilation in the original Haskell source file. For example, if the .hs file contains something like #ifdef mingw32_HOST_OS, then the .hc and .hi files will both be Windows-only. There are certainly many instances of this in the libraries right now. Another problem is the configuration information that gets into the build via the autoconf scripts. Things like the size of C types in Foreign.C.Types, or the errno values in Foreign.C.Error might be different on the target machine. I hope I've managed to understand your question correctly... if not please ask again! Cheers, Simon From r.kelsall at millstream.com Wed May 14 10:08:51 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Wed May 14 10:02:33 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? Message-ID: <482AF273.90407@millstream.com> Hello Glasgow-Haskell Users, It was suggested to me in this thread in Haskell-Cafe http://www.haskell.org/pipermail/haskell-cafe/2008-May/042797.html which was a subsidiary of a previous thread http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html that there might be some reason other than the -O2 optimisation level I applied to my version of splitAt that was making my program run about 30% faster than when I used the built-in splitAt. Can somebody tell me how to check what the -O level is for the built-in splitAt? Or alternatively tell me what the optimisation level is for the libraries. (Sorry I'm not sure of the right terminology for these built-in / library / Prelude things.) Richard. From sedillard at ucdavis.edu Wed May 14 11:31:08 2008 From: sedillard at ucdavis.edu (Scott Dillard) Date: Wed May 14 11:24:50 2008 Subject: laziness, memoization and inlining In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: Simon, Don, You're right. -fno-state-hack fixed it. I've opened a trac ticket. Program and test data are there. http://hackage.haskell.org/trac/ghc/ticket/2284 Scott On Wed, May 14, 2008 at 1:48 AM, Simon Peyton-Jones wrote: > Scott > > | I'm experiencing some undesirable performance behavior, I suspect from > | inlining things that shouldn't be, defeating my memoization attempts. > > This is bad, very bad. I think Don is right. I believe the following is happening. In your main program you have > > do let mesh = memoMesh rawMesh > display :: IO () > display = draw mesh >> stuff > setDisplayCallback display > glutMainLoop > > So the effect is that 'display' is performed many times, by glutMainLoop. > > Now 'display' is seen by GHC thus: > display = \s -> draw mesh s >> stuff > > The "\s" says "given the state of the world, s, I'll draw the mesh on it". The "state hack" makes GHC think that a "\s" will only ever be called once (which is utterly false in this case), so it can inline mesh=memoMesh rawMesh. Result disaster. > > > I bet you'll be fine if you compile your main module with -fno-state-hack. > > But I should fix this, somehow. It's coming up too often to justify the hack. Can you make a Trac bug report, and include your message and this one? > > Thanks for reporting it. > > Simon > From alexander.fuchs at uni-koblenz.de Wed May 14 12:58:11 2008 From: alexander.fuchs at uni-koblenz.de (Alexander Fuchs) Date: Wed May 14 12:52:04 2008 Subject: Performance: Faster to define a function writing out all arguments? In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C32AE562B82F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <4821BBC0.5040601@uni-koblenz.de> <20080508214026.GD3528@scytale.galois.com> <482867A4.6020102@uni-koblenz.de> <20080512232847.GO8256@scytale.galois.com> <638ABD0A29C8884A91BC5FB5C349B1C32AE562B82F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <482B1A23.6000307@uni-koblenz.de> Hi. Simon Peyton-Jones wrote: > | I've definitely run into the odd other case where point-freeing > | a bit of code messes with the complexity. > > That should not happen -- except for the state-hack. Which is this: > > Consider > f1 :: Char -> IO () > f1 = \c. let i = ord c in \s. print i s > > Here s::State World. Is this equivalent to > f2 = \c.\s. print (ord c) s > > The latter is very much more efficient than 'f1', because it doesn't build an intermediate lambda. This matters a lot in I/O-intensive programs. But if 'f' is called thus: > > forever (f 'w') > > then (ord 'w') is computed once for each call of f2, but is shared among all calls to f1. And that can make a big difference too. Thanks for the explanation. State World here really means the IO and ST monad, not the State monad, right? Compiling with -fno-state-hack actually does actually lead to both versions (the point-free and explicit) being equally fast (14.4s instead of 15.2s resp. 14.0s). Though I am not sure why. Running in profiled mode makes all difference vanish. I tested this on an Intel(R) Pentium(R) 4 CPU 3.00GHz and got the reported speed difference there. Using instead an AMD Athlon(tm) 64 Processor 3800+ I got no difference even without using -fno-state-hack. > I have no idea whether this is playing a role in the example you are discussing -- my guess is not, and there may be another performance bug lurking. So eliciting a small demo would be great. I am sorry, I completely failed to do that. The parser builds up a data structure from several data types using memoization. Any significant simplification of the code base reduced the performance gap until it quickly disappeared. Alexander From kili at outback.escape.de Wed May 14 14:38:54 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Wed May 14 14:33:48 2008 Subject: How MD are .hi files? In-Reply-To: <482AC078.6000802@gmail.com> References: <20080512195733.GA2091@petunia.outback.escape.de> <482AC078.6000802@gmail.com> Message-ID: <20080514183853.GB16920@petunia.outback.escape.de> On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: > >for an unregisterised ghc-6.8.2 (or newer), are the .hi files > >dependent (except for the 32 vs. 64 bit word size)? I had a quick > >look at the stuff in compiler/iface, but the only MD part I found > >was that 32/64 bit difference. > > The word size is probably the only dependency, but there are many reasons > that you can't just take the .hc/.hi files generated by an unregisterised > build on one machine and expect them to work on another machine. I really don't expect this. I just decided to be lazy and provide not only .hc files but also .hi files[1] for the OpenBSD port, and then I thought: "does this make sense at all? Can it even be of use for porting GHC to other archs on OpenBSD, or for the NetBSD folks working on GHC?" Ciao, Kili [1] Of course, the correct solution would not need the .hi files, but just use the stage1 bootstrapped from .hc files to start rebuilding the libraries. But that would require even more hacking on the Makefiles, and I've already an insane amount of hacks sitting around. -- It compiles -- let's ship it! From marlowsd at gmail.com Thu May 15 05:29:50 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 05:23:36 2008 Subject: How MD are .hi files? In-Reply-To: <20080514183853.GB16920@petunia.outback.escape.de> References: <20080512195733.GA2091@petunia.outback.escape.de> <482AC078.6000802@gmail.com> <20080514183853.GB16920@petunia.outback.escape.de> Message-ID: <482C028E.9090104@gmail.com> Matthias Kilian wrote: > On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote: >>> for an unregisterised ghc-6.8.2 (or newer), are the .hi files >>> dependent (except for the 32 vs. 64 bit word size)? I had a quick >>> look at the stuff in compiler/iface, but the only MD part I found >>> was that 32/64 bit difference. >> The word size is probably the only dependency, but there are many reasons >> that you can't just take the .hc/.hi files generated by an unregisterised >> build on one machine and expect them to work on another machine. > > I really don't expect this. I just decided to be lazy and provide > not only .hc files but also .hi files[1] for the OpenBSD port, and > then I thought: "does this make sense at all? Can it even be of use > for porting GHC to other archs on OpenBSD, or for the NetBSD folks > working on GHC?" Here's a message I wrote quite a while ago on this topic: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-May/008456.html some of that is out of date, but at least it describes most of the issues with having a platform-independen hc bootstrap. > [1] Of course, the correct solution would not need the .hi files, > but just use the stage1 bootstrapped from .hc files to start > rebuilding the libraries. But that would require even more hacking > on the Makefiles, and I've already an insane amount of hacks sitting > around. If the .hc files were platform independent, then the .hi files would be too, by definition. Cheers, Simon From marlowsd at gmail.com Thu May 15 05:31:32 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 05:25:16 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <482AF273.90407@millstream.com> References: <482AF273.90407@millstream.com> Message-ID: <482C02F4.8050202@gmail.com> Richard Kelsall wrote: > Hello Glasgow-Haskell Users, > > It was suggested to me in this thread in Haskell-Cafe > > http://www.haskell.org/pipermail/haskell-cafe/2008-May/042797.html > > which was a subsidiary of a previous thread > > http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html > > that there might be some reason other than the -O2 optimisation level > I applied to my version of splitAt that was making my program run about > 30% faster than when I used the built-in splitAt. > > Can somebody tell me how to check what the -O level is for the built-in > splitAt? Or alternatively tell me what the optimisation level is for > the libraries. > > (Sorry I'm not sure of the right terminology for these built-in / > library / Prelude things.) It's hard to tell what optimisation level your libraries were compiled with. The default setting is -O, but when building binary distributions we usually set it explicitly to -O2. If you got your binary from another source, they might have only used -O. Cheers, Simon From marlowsd at gmail.com Thu May 15 05:35:27 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 15 05:29:10 2008 Subject: laziness, memoization and inlining In-Reply-To: References: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <482C03DF.9080108@gmail.com> Scott Dillard wrote: > Simon, Don, > > You're right. -fno-state-hack fixed it. I've opened a trac ticket. > Program and test data are there. > > http://hackage.haskell.org/trac/ghc/ticket/2284 Ok, but do we really need two tickets for this? Why open a new ticket rather than adding the information to the existing ticket? Cheers, Simon From bulat.ziganshin at gmail.com Thu May 15 05:54:09 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 15 05:48:01 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <482C02F4.8050202@gmail.com> References: <482AF273.90407@millstream.com> <482C02F4.8050202@gmail.com> Message-ID: <1392674559.20080515135409@gmail.com> Hello Simon, Thursday, May 15, 2008, 1:31:32 PM, you wrote: > It's hard to tell what optimisation level your libraries were compiled > with. The default setting is -O, but when building binary distributions we > usually set it explicitly to -O2. If you got your binary from another > source, they might have only used -O. not surprising that noone answered this question in cafe :) actually, main Windows builds goes from Sigbjorn Finne afair. may be from Neil too. so we probably need to warn them that their builds may be sub-optimal? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Thu May 15 06:15:19 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu May 15 06:09:02 2008 Subject: laziness, memoization and inlining In-Reply-To: <482C03DF.9080108@gmail.com> References: <638ABD0A29C8884A91BC5FB5C349B1C32AE569F9B1@EA-EXMSG-C334.europe.corp.microsoft.com> <482C03DF.9080108@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE56A033F@EA-EXMSG-C334.europe.corp.microsoft.com> i'd forgotten there was an existing one when I asked Scott document his problem. I've cross-linked them, but equally good would be to transfer the info | -----Original Message----- | From: Simon Marlow [mailto:simonmarhaskell@gmail.com] On Behalf Of Simon Marlow | Sent: 15 May 2008 10:35 | To: Scott Dillard | Cc: Simon Peyton-Jones; Don Stewart; glasgow-haskell-users@haskell.org | Subject: Re: laziness, memoization and inlining | | Scott Dillard wrote: | > Simon, Don, | > | > You're right. -fno-state-hack fixed it. I've opened a trac ticket. | > Program and test data are there. | > | > http://hackage.haskell.org/trac/ghc/ticket/2284 | | Ok, but do we really need two tickets for this? Why open a new ticket | rather than adding the information to the existing ticket? | | Cheers, | Simon From r.kelsall at millstream.com Thu May 15 09:13:32 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Thu May 15 09:07:19 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <1392674559.20080515135409@gmail.com> References: <482AF273.90407@millstream.com> <482C02F4.8050202@gmail.com> <1392674559.20080515135409@gmail.com> Message-ID: <482C36FC.2010003@millstream.com> Bulat Ziganshin wrote: > Hello Simon, > >> It's hard to tell what optimisation level your libraries were compiled >> with. The default setting is -O, but when building binary distributions we >> usually set it explicitly to -O2. If you got your binary from another >> source, they might have only used -O. > > not surprising that noone answered this question in cafe :) > > actually, main Windows builds goes from Sigbjorn Finne afair. may be > from Neil too. so we probably need to warn them that their builds may > be sub-optimal? > Thanks chaps, For the record I'm using the Windows version of GHC 6.8.2 downloaded from here http://haskell.org/ghc/download_ghc_682.html MD5 is 5356a12f056a32ef35fa44db2e2204fc I just downloaded the one that's there currently and it's the same as the one I'm using which I think I downloaded in January. Richard. From stefan at cs.uu.nl Thu May 15 09:46:57 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu May 15 09:40:35 2008 Subject: Type checker loops with innocent looking associated type synonym Message-ID: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> I've written this cute ;-) piece of code involving an associated type synonym, {-# OPTIONS_GHC -fglasgow-exts #-} class ZipWithA a where type Elem a :: * zipWithA :: [Elem a] -> a instance ZipWithA [a] where type Elem [a] = a zipWithA xs = xs instance ZipWithA b => ZipWithA ([a] -> b) where type Elem ([a] -> b) = a -> Elem b zipWithA fs = zipWithA . zipWith ($) fs and it behaves as intended: *Main> zipWithA [2, 3] :: [Int] [2,3] *Main> zipWithA [pred, succ] [2, 3] :: [Int] [1,4] *Main> zipWithA [(+), (-)] [2, 3] [5, 7] :: [Int] [7,-4] However, as soon as the overloading cannot be resolved, the type checker loops: *Main> zipWithA [head, last] ["more than", "haskell"] :: String "ml" *Main> zipWithA [head, last] ["more than", "haskell"] <> Just to be clear, I do not expect GHC to be able to type this last example, I would just have thought it would want to tell me in finite time that it cannot resolve the overloading here. Should I report this a bug? Or is it perhaps already been taken care of in the head? Or am I just plain unreasonable here? :-) Cheers, Stefan From igloo at earth.li Thu May 15 10:05:15 2008 From: igloo at earth.li (Ian Lynagh) Date: Thu May 15 09:58:58 2008 Subject: How do I check the optimisation level of the built-in splitAt? Is something other than -O2 giving me my speed increase? In-Reply-To: <482C36FC.2010003@millstream.com> References: <482AF273.90407@millstream.com> <482C02F4.8050202@gmail.com> <1392674559.20080515135409@gmail.com> <482C36FC.2010003@millstream.com> Message-ID: <20080515140514.GA24952@matrix.chaos.earth.li> On Thu, May 15, 2008 at 02:13:32PM +0100, Richard Kelsall wrote: > Bulat Ziganshin wrote: > >Hello Simon, > > > >>It's hard to tell what optimisation level your libraries were compiled > >>with. The default setting is -O, but when building binary distributions > >>we > >>usually set it explicitly to -O2. If you got your binary from another > >>source, they might have only used -O. > > > >not surprising that noone answered this question in cafe :) > > > >actually, main Windows builds goes from Sigbjorn Finne afair. may be > >from Neil too The builds were always done on MSR machines, although Sigbjorn used to bundle them up into installers. These days the MSR machines make the installers too, with a script from Neil. > For the record I'm using the Windows version of GHC 6.8.2 downloaded > from here > > http://haskell.org/ghc/download_ghc_682.html I'm pretty sure that's got the libraries built with -O, although I haven't looked for the log of that actual build. We only use -O2 on the Linux builds as far as I can see, but I'm not sure there's a good reason for that. I also don't know why we don't just make our preferred settings the default in the build system; Simon? Thanks Ian From bulat.ziganshin at gmail.com Thu May 15 10:26:37 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 15 10:20:49 2008 Subject: Type checker loops with innocent looking associated type synonym In-Reply-To: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> References: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> Message-ID: <969114973.20080515182637@gmail.com> Hello Stefan, Thursday, May 15, 2008, 5:46:57 PM, you wrote: > class ZipWithA a where > type Elem a :: * > Should I report this a bug? Or is it perhaps already been taken care > of in the head? Or am I just plain unreasonable here? :-) afair, the rule of thumb is: please don't report us errors with type families in 6.8 - it's unofficial and incomplete here. test against HEAD if you are really interested -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Thu May 15 14:47:20 2008 From: dons at galois.com (Don Stewart) Date: Thu May 15 14:41:01 2008 Subject: -optc-O2 considered useful Message-ID: <20080515184720.GE31635@scytale.galois.com> I discovered something today I didn't know. gcc -O2 can optimise out the computed jumps GHC produces in tight loops. Consider this program, import Data.Array.Vector import Data.Bits main = print . sumU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) Yields this core: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sMp :: Int#) (ww1_sMt :: Int#) -> case ww1_sMt of wild_X10 { __DEFAULT -> $wfold (+# ww_sMp 40) (+# wild_X10 1); 100000000 -> ww_sMp And -O2 -fasm: Main_zdwfold_info: movq %rdi,%rax cmpq $100000000,%rax jne .LcOk movq %rsi,%rbx jmp *(%rbp) .LcOk: incq %rax addq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info $ time ./sum 4000000000 ./sum 0.19s user 0.00s system 101% cpu 0.188 total -O2 -fvia-C -optc-O: Main_zdwfold_info: cmpq $100000000, %rdi jne .L3 movq %rsi, %rbx movq (%rbp), %rax .L4: jmp *%rax .L3: addq $40, %rsi leaq 1(%rdi), %rdi movl $Main_zdwfold_info, %eax jmp .L4 $ time ./sum 4000000000 ./sum 0.34s user 0.00s system 94% cpu 0.361 total Hmm. That movl, jmp .L4 ; jmp *%rax looks sucky, and performance got worse. And now with -O2 -fvia-C -optc-O2 Main_zdwfold_info: cmpq $100000000, %rdi je .L5 .L3: addq $40, %rsi leaq 1(%rdi), %rdi jmp Main_zdwfold_info $ time ./sum 4000000000 ./sum 0.11s user 0.02s system 106% cpu 0.122 total Woot, back in business. -- Don From bulat.ziganshin at gmail.com Thu May 15 15:00:26 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu May 15 15:05:01 2008 Subject: -optc-O2 considered useful In-Reply-To: <20080515184720.GE31635@scytale.galois.com> References: <20080515184720.GE31635@scytale.galois.com> Message-ID: <1693468577.20080515230026@gmail.com> Hello Don, Thursday, May 15, 2008, 10:47:20 PM, you wrote: > I discovered something today I didn't know. > gcc -O2 can optimise out the computed jumps GHC produces in tight loops. seems that decision to use native backend in ghc -O2 was too early? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Thu May 15 18:31:51 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 15 18:23:38 2008 Subject: -optc-O2 considered useful In-Reply-To: <1693468577.20080515230026@gmail.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> Message-ID: <1210890711.5824.157.camel@localhost> On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote: > Hello Don, > > Thursday, May 15, 2008, 10:47:20 PM, you wrote: > > > I discovered something today I didn't know. > > gcc -O2 can optimise out the computed jumps GHC produces in tight loops. > > seems that decision to use native backend in ghc -O2 was too early? Though note that the native backend never introduced the computed jump. I think it's clear that -fvia-C -O should imply -optc-O2 if it does not already. gcc -O0 is for painfully obvious C translation into assembler, -O is for quick optimisations. gcc -O2 is the "standard" optimisation level used for building packages for most distros. Duncan From dons at galois.com Thu May 15 18:37:26 2008 From: dons at galois.com (Don Stewart) Date: Thu May 15 18:31:09 2008 Subject: -optc-O2 considered useful In-Reply-To: <1210890711.5824.157.camel@localhost> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> Message-ID: <20080515223726.GL31635@scytale.galois.com> duncan.coutts: > > On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote: > > Hello Don, > > > > Thursday, May 15, 2008, 10:47:20 PM, you wrote: > > > > > I discovered something today I didn't know. > > > gcc -O2 can optimise out the computed jumps GHC produces in tight loops. > > > > seems that decision to use native backend in ghc -O2 was too early? > > Though note that the native backend never introduced the computed jump. > > I think it's clear that -fvia-C -O should imply -optc-O2 if it does not > already. gcc -O0 is for painfully obvious C translation into assembler, > -O is for quick optimisations. gcc -O2 is the "standard" optimisation > level used for building packages for most distros. Another idea: should -fstrictness be on by default? I run into too many users writing little tail recursive Int loops, and not using optimisations, with the impression that compiling, e.g. ghc A.hs should just work. -- Don From marlowsd at gmail.com Fri May 16 05:38:46 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Fri May 16 05:32:27 2008 Subject: -optc-O2 considered useful In-Reply-To: <20080515223726.GL31635@scytale.galois.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> <20080515223726.GL31635@scytale.galois.com> Message-ID: <482D5626.5010606@gmail.com> Don Stewart wrote: > duncan.coutts: >> On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote: >>> Hello Don, >>> >>> Thursday, May 15, 2008, 10:47:20 PM, you wrote: >>> >>>> I discovered something today I didn't know. >>>> gcc -O2 can optimise out the computed jumps GHC produces in tight loops. >>> seems that decision to use native backend in ghc -O2 was too early? >> Though note that the native backend never introduced the computed jump. >> >> I think it's clear that -fvia-C -O should imply -optc-O2 if it does not >> already. gcc -O0 is for painfully obvious C translation into assembler, >> -O is for quick optimisations. gcc -O2 is the "standard" optimisation >> level used for building packages for most distros. > > Another idea: > > should -fstrictness be on by default? > > I run into too many users writing little tail recursive Int loops, and > not using optimisations, with the impression that compiling, e.g. > > ghc A.hs > > should just work. This is part of a larger question, namely whether we can get substantial benefit for doing a tiny bit of extra work in -O0. With -O0 we're optimising for compile time in preference to code speed, although we do want to find a good compromise that doesn't generate abysmal code. I bet there are things we can do with -O0 that would generate significantly better code in some cases, without increasing compile times, and perhaps even decreasing compile times due to the reduction in the amount of code being generated. As for the specific issue of whether we should turn on -fstrictness with -O0, I suspect the answer is that the compile-time cost would be too high. Cheers, Simon From ndmitchell at gmail.com Fri May 16 08:00:20 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri May 16 07:53:57 2008 Subject: -optc-O2 considered useful In-Reply-To: <482D5626.5010606@gmail.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> <20080515223726.GL31635@scytale.galois.com> <482D5626.5010606@gmail.com> Message-ID: <404396ef0805160500h5e04a05egec3dc80ba6b966f@mail.gmail.com> Hi > As for the specific issue of whether we should turn on -fstrictness with > -O0, I suspect the answer is that the compile-time cost would be too high. There would also be the issue that it would increase the amount of Haskell code which works only in GHC, which is probably a bad thing. Would the strictness still recover the loop if they turned on hpc/profiling? I can see many reasons why making things faster is good, but making things asymptotically faster/less space in -O0 could bite later. One ticket that probably makes a big difference in -O0 is: http://hackage.haskell.org/trac/ghc/ticket/2207 Thanks Neil From dominic.steinitz at blueyonder.co.uk Fri May 16 14:09:39 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Fri May 16 14:03:12 2008 Subject: Building GHC Message-ID: <482DCDE3.3040105@blueyonder.co.uk> When I look at the instructions http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources they say the distribution is split in two but when I look at http://darcs.haskell.org/ it seems to be split in three ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:25 102M ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:20 92M ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:12 57M I'm assuming I unpack these on top of each other but I'd be grateful if someone could confirm this. Thanks, Dominic. From igloo at earth.li Fri May 16 17:13:20 2008 From: igloo at earth.li (Ian Lynagh) Date: Fri May 16 17:06:56 2008 Subject: Building GHC In-Reply-To: <482DCDE3.3040105@blueyonder.co.uk> References: <482DCDE3.3040105@blueyonder.co.uk> Message-ID: <20080516211320.GA7862@matrix.chaos.earth.li> Hi Dominic, On Fri, May 16, 2008 at 07:09:39PM +0100, Dominic Steinitz wrote: > When I look at the instructions > > http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources That's talking about the sources of a release, from a page like http://www.haskell.org/ghc/download_ghc_682.html > they say the distribution is split in two but when I look at > > http://darcs.haskell.org/ > > it seems to be split in three > > ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:25 102M > ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:20 92M > ghc-HEAD-2007-12-16-..> 16-Dec-2007 14:12 57M These are darcs source snapshots. The filenames are ghc-HEAD-2007-12-16-ghc-corelibs-testsuite.tar.bz2 ghc-HEAD-2007-12-16-ghc-corelibs.tar.bz2 ghc-HEAD-2007-12-16-ghc.tar.bz2 The first includes all of the second, which in turn includes all of the third. > I'm assuming I unpack these on top of each other but I'd be grateful if > someone could confirm this. No, you only want one of them - probably the first one. I don't think it includes the most recent library split, so you'll need to ./darcs-all get after untarring it. Thanks Ian From isaacdupree at charter.net Fri May 16 20:17:17 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri May 16 20:10:54 2008 Subject: -optc-O2 considered useful In-Reply-To: <482D5626.5010606@gmail.com> References: <20080515184720.GE31635@scytale.galois.com> <1693468577.20080515230026@gmail.com> <1210890711.5824.157.camel@localhost> <20080515223726.GL31635@scytale.galois.com> <482D5626.5010606@gmail.com> Message-ID: <482E240D.5080504@charter.net> Simon Marlow wrote: > This is part of a larger question, namely whether we can get substantial > benefit for doing a tiny bit of extra work in -O0. With -O0 we're > optimising for compile time in preference to code speed, although we do > want to find a good compromise that doesn't generate abysmal code. there's the other use of -O0, namely, debugging the compiler -- but then, debugging the optimizations probably requires pretty specific knowledge of what you're looking for, anyway, and testing on multiple platforms usually finds out whether a problem is with a port or with the compilation process. oh, and also that profiling/debugging optimized code can be confusing, so it might be good to avoid optimizations that have too much of that effect -Isaac From bertram.felgenhauer at googlemail.com Sat May 17 00:33:08 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat May 17 00:26:51 2008 Subject: Experiment: ghc-api and --split-objs Message-ID: <20080517043307.GB10526@zombie.inf.tu-dresden.de> Hi, I've made an experiment compiling ghc-api with --split-objs. To summarize, while this is not worthwhile for the compiler itself, it could be a huge win for plugin libraries. A fairly detailed description can be found here, http://int-e.home.tlink.de/haskell/README.ghc-api-test A tarball with the examples and auxiliary files is at http://int-e.home.tlink.de/haskell/ghc-api-test.tar.bz2 Open questions: - How much work would it to do this within the ghc build? - Maybe users that only need the parser can win as well? Haddock comes to mind here. In any case, this is food for thought, I hope. Enjoy, Bertram From conal at conal.net Sat May 17 23:38:56 2008 From: conal at conal.net (Conal Elliott) Date: Sat May 17 23:32:27 2008 Subject: whence _stub.c ? Message-ID: what causes ghc to emit a stub.c file? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20080517/1d05b481/attachment-0001.htm From dons at galois.com Sat May 17 23:48:19 2008 From: dons at galois.com (Don Stewart) Date: Sat May 17 23:41:57 2008 Subject: whence _stub.c ? In-Reply-To: References: Message-ID: <20080518034819.GE25300@scytale.galois.com> > what causes ghc to emit a stub.c file? - Conal the use of 'foreign export' - Don From mechvel at botik.ru Sun May 18 09:01:51 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sun May 18 08:55:24 2008 Subject: making Happy Message-ID: <20080518130151.GA30353@scico.botik.ru> People, please, how can I download happy-1.14 source ? I need to install ghc-6.8.2 from source, and this needs Happy -- right? I would like to build Happy from source. Its page shows only 1.17. 1.14 was easy to build in a standard way: ./configue --path=... make make install And in 1.17, I am looking into its unzipped root directory, and do not see how to make and install. Generally, it is good to show an easy way to make and install somewhere in the root, in README ... Probably, Happy is a wise and remarkable project. But many people need only to `make' GHC, and do not intend to study right now many documents and philosophy about Happy and Cabal, etc. Thank you in advance for your help, ----------------- Serge Mechveliani mechvel@botik.ru From duncan.coutts at worc.ox.ac.uk Sun May 18 10:54:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun May 18 10:45:41 2008 Subject: making Happy In-Reply-To: <20080518130151.GA30353@scico.botik.ru> References: <20080518130151.GA30353@scico.botik.ru> Message-ID: <1211122440.5824.236.camel@localhost> On Sun, 2008-05-18 at 17:01 +0400, Serge D. Mechveliani wrote: > People, > > please, how can I download happy-1.14 source ? > > I need to install ghc-6.8.2 from source, and this needs Happy > -- right? > I would like to build Happy from source. Its page shows only 1.17. > 1.14 was easy to build in a standard way: ./configue --path=... > make > make install The standard procedure for installing cabal packages is pretty similar: runghc Setup configure --prefix=... runghc Setup build runghc Setup install For those brave souls helping us test cabal-install it's even simpler: cabal install happy Duncan From daniel.is.fischer at web.de Sun May 18 11:15:33 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun May 18 11:07:12 2008 Subject: making Happy In-Reply-To: <20080518130151.GA30353@scico.botik.ru> References: <20080518130151.GA30353@scico.botik.ru> Message-ID: <200805181715.33265.daniel.is.fischer@web.de> Am Sonntag, 18. Mai 2008 15:01 schrieb Serge D. Mechveliani: > People, > > please, how can I download happy-1.14 source ? > > I need to install ghc-6.8.2 from source, and this needs Happy > -- right? > I would like to build Happy from source. Its page shows only 1.17. > 1.14 was easy to build in a standard way: ./configue --path=... > make > make install > And in 1.17, I am looking into its unzipped root directory, and do not > see how to make and install. > Generally, it is good to show an easy way to make and install somewhere > in the root, in README ... > Probably, Happy is a wise and remarkable project. But many people need > only to `make' GHC, and do not intend to study right now many documents > and philosophy about Happy and Cabal, etc. > > Thank you in advance for your help, > > ----------------- > Serge Mechveliani > mechvel@botik.ru > If you don't want to go the cabal way, I could send you happy-1.15-src.tar.gz, that builds with ./configure; make; make install, too. From bulat.ziganshin at gmail.com Sun May 18 11:33:02 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun May 18 11:34:18 2008 Subject: bug in 6.8.2? Message-ID: <1113146976.20080518193302@gmail.com> Hello glasgow-haskell-users, i've rather complicated class structure: class BufferData a where instance (FastBufferData a) => BufferData a where class FastBufferData a where instance (Storable a) => FastBufferData a where of course, it's compiled with -fallow-undecidable-instances -fallow-overlapping-instances -fallow-incoherent-instances BufferData class includes procedure `write`: class BufferData a where write :: OutStream -> a -> IO () there is writeAll procedure which uses this `write` and therefore should be able to write any BufferData instance: writeAll receiveBuf sendBuf cleanup x = bracket (create receiveBuf sendBuf cleanup) (closeOut) (\buf -> write buf x) it works great in 6.6.1 but in 6.8.2 GHC infers that writeAll can write only Storable instances, so i was forced to add signature to writeAll: writeAll :: (BufferData a) => RecvBuf -> SendBuf -> Cleanup -> a -> IO () the same problems raised many times when i switched from 6.6.1 to 6.8.2 - lots of procedures need to add signatures because by default 6.8.2 decided that they are restricted to Storable does GHC developers interested in minimal test case for this problem? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Mon May 19 07:00:40 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon May 19 06:54:10 2008 Subject: bug in 6.8.2? In-Reply-To: <1113146976.20080518193302@gmail.com> References: <1113146976.20080518193302@gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE570832C@EA-EXMSG-C334.europe.corp.microsoft.com> | class BufferData a where | write :: OutStream -> a -> IO () | | there is writeAll procedure which uses this `write` and therefore | should be able to write any BufferData instance: | | writeAll receiveBuf sendBuf cleanup x = | bracket (create receiveBuf sendBuf cleanup) (closeOut) | (\buf -> write buf x) | | it works great in 6.6.1 but in 6.8.2 GHC infers that writeAll can | write only Storable instances, so i was forced to add signature to | writeAll: Ah, well. You have write :: BufferData a => ... So a call to write gives rise to the constraint (BufferData a). Ah, but there's an instance declaration for that, so GHC simplifies it using. instance (FastBufferData a) => BufferData a where Now we need (FastBufferData a). Ah, there's an instance for that too. instance (Storable a) => FastBufferData a where Oh, you say, I didn't want GHC to simplify (BufferData a), because in a *call* of writeAll, I might instantiate 'a' to T, and I have a more specialised instance of (BufferData T). Fair enough. And indeed, GHC is *supposed* to refrain from using the (BufferData a) instance if it sees *any* more specialised instance. UNLESS a) it can only "see" the (BufferData a) instance, so it doesn't know there are more specialised one b) you specify -fallow-incoherent-instances. Which you do. So you get, well, incoherence. I suspect you are being bitten by (b). The incoherent-instance thing is the most dodgy of GHC's type-class flags. Are you sure you want it? Simon From mechvel at botik.ru Mon May 19 08:37:40 2008 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon May 19 08:31:09 2008 Subject: making GHC from source Message-ID: <20080519123740.GA4798@scico.botik.ru> People, I need to install ghc-6.8.2 from source. As I recall, this needs Happy and Alex. Right? Among Happy versions, it is visible only a couple latest ones, and to install any of them, one needs Cabal. Installing Cabal is as follows: make install mkdir -p dist/tmp ghc --make -cpp -Wall -DCABAL_VERSION=1,2,3,0 -i. -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup make: ghc: command not found. We have a `make' loop: ghc --> Happy --> Cabal --> ghc Old Happy was good: it did not require GHC -- as I recall. Do I mistake? Now I have to install GHC from binary, and it will report of library version mismatch ... and so on. Do not you think that, generally, something is going wrong here? Regards, ----------------- Serge Mechveliani mechvel@botik.ru http://www.botik.ru/~mechvel From duncan.coutts at worc.ox.ac.uk Mon May 19 14:31:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon May 19 14:22:31 2008 Subject: making GHC from source In-Reply-To: <20080519123740.GA4798@scico.botik.ru> References: <20080519123740.GA4798@scico.botik.ru> Message-ID: <1211221860.5824.443.camel@localhost> On Mon, 2008-05-19 at 16:37 +0400, Serge D. Mechveliani wrote: > People, > > I need to install ghc-6.8.2 from source. > As I recall, this needs Happy and Alex. Right? No, not if you are using a released ghc tarball because they include the output of happy and alex. You only need happy and alex if you want to build the development version of ghc from darcs. > Among Happy versions, it is visible only a couple latest ones, and to install > any of them, one needs Cabal. > Installing Cabal is as follows: > make install > mkdir -p dist/tmp > ghc --make -cpp -Wall -DCABAL_VERSION=1,2,3,0 -i. -odir dist/tmp > -hidir dist/tmp Setup.lhs -o setup > make: ghc: command not found. > > We have a `make' loop: ghc --> Happy --> Cabal --> ghc Remember that you always need an existing ghc binary to be able to build ghc from source. > Old Happy was good: it did not require GHC -- as I recall. Do I mistake? Happy is written in Haskell and typically people build it from source using GHC. > Now I have to install GHC from binary, and it will report of library version mismatch ... > and so on. > Do not you think that, generally, something is going wrong here? You'll need at least a ghc binary to bootstrap with. See the ghc building guide: http://hackage.haskell.org/trac/ghc/wiki/Building Duncan From marlowsd at gmail.com Tue May 20 03:54:10 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue May 20 03:47:40 2008 Subject: Experiment: ghc-api and --split-objs In-Reply-To: <20080517043307.GB10526@zombie.inf.tu-dresden.de> References: <20080517043307.GB10526@zombie.inf.tu-dresden.de> Message-ID: <483283A2.2050207@gmail.com> Bertram Felgenhauer wrote: > I've made an experiment compiling ghc-api with --split-objs. To > summarize, while this is not worthwhile for the compiler itself, > it could be a huge win for plugin libraries. > > A fairly detailed description can be found here, > http://int-e.home.tlink.de/haskell/README.ghc-api-test > > A tarball with the examples and auxiliary files is at > http://int-e.home.tlink.de/haskell/ghc-api-test.tar.bz2 > > Open questions: > - How much work would it to do this within the ghc build? > - Maybe users that only need the parser can win as well? Haddock > comes to mind here. > > In any case, this is food for thought, I hope. I hope that for 6.10 we'll have shared libraries working on the major platforms, so split-objs should be a non-issue. For platforms where we don't have shared libraries, or perhaps if we want to have static-only distributions, then probably enabling split-objs for stage 2 would be a good idea, yes. Cheers, Simon From marlowsd at gmail.com Tue May 20 03:54:44 2008 From: marlowsd at gmail.com (Simon Marlow) Date: Tue May 20 03:48:12 2008 Subject: whence _stub.c ? In-Reply-To: <20080518034819.GE25300@scytale.galois.com> References: <20080518034819.GE25300@scytale.galois.com> Message-ID: <483283C4.3050401@gmail.com> Don Stewart wrote: >> what causes ghc to emit a stub.c file? - Conal > > the use of 'foreign export' - Don or 'foreign import "wrapper"' From bbr at informatik.uni-kiel.de Tue May 20 05:31:51 2008 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Tue May 20 05:26:01 2008 Subject: -optc-O2 considered useful Message-ID: <48329A87.705@informatik.uni-kiel.de> I think it would be nice to have some speedy optimizations turned on by default in ghc. Might even be good to win new users. But I also think that much hacking for and around ghc+tool support needs a way to achieve what -O0 does today. So, how about an -O(-1) or flag? From chak at cse.unsw.edu.au Tue May 20 23:38:55 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue May 20 23:32:19 2008 Subject: Type checker loops with innocent looking associated type synonym In-Reply-To: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> References: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> Message-ID: Stefan Holdermans: > Should I report this a bug? Or is it perhaps already been taken care > of in the head? Probably the latter. But really as, Bulat wrote, type families in 6.8 are unsupported. Please test your code with a HEAD snapshot. If that goes wrong, a bug report on Trac would be most appreciated. Manuel From hp at rentec.com Wed May 21 12:11:56 2008 From: hp at rentec.com (HP Wei) Date: Wed May 21 12:05:17 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: Suppose p1, p2, p3 are 3 predicates that take an input -- say, a String. They return either (True, result) or False. I want to get an effect like in this expression: case p1 s of (True, r) -> r False -> case p2 s of (True, r) -> r False -> case p3 s of (True, r) -> r False -> none Is this a job for Maybe monad ? How do I do that ? Thanks HP From hp at rentec.com Wed May 21 12:21:01 2008 From: hp at rentec.com (HP Wei) Date: Wed May 21 12:14:20 2008 Subject: ghc compiler <--- ld -R ? In-Reply-To: References: Message-ID: In the linker ld, there is a -R option to encode lib-search-directories into the object file. Can we not do that in compiling this ghc -o foo --make foo.hs ??? Thanks HP From bulat.ziganshin at gmail.com Wed May 21 12:31:42 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 21 12:27:26 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: <1453427852.20080521203142@gmail.com> Hello HP, Wednesday, May 21, 2008, 8:11:56 PM, you wrote: > Suppose p1, p2, p3 are 3 predicates > that take an input -- say, a String. > They return either (True, result) > or False. impossible because these are different types :)) if they return Just result or Nothing - yes, use Maybe as monad: combine p1 p2 p3 x= do x1 <- p1 x x2 <- p2 x1 x3 <- p3 x2 return x3 or shortly combine p1 p2 p3 x = p1 x >>= p2 >>= p3 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed May 21 12:33:16 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 21 12:29:26 2008 Subject: ghc compiler <--- ld -R ? In-Reply-To: References: Message-ID: <668354053.20080521203316@gmail.com> Hello HP, Wednesday, May 21, 2008, 8:21:01 PM, you wrote: > In the linker ld, there is a -R option example of passing option to ld: ghc ... -optl-Xlinker -optl--large-address-aware -optl-Xlinker may be optional -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From daniel.is.fischer at web.de Wed May 21 12:57:01 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed May 21 12:48:33 2008 Subject: how do I abstract this pattern ? In-Reply-To: <1453427852.20080521203142@gmail.com> References: <1453427852.20080521203142@gmail.com> Message-ID: <200805211857.01686.daniel.is.fischer@web.de> Am Mittwoch, 21. Mai 2008 18:31 schrieb Bulat Ziganshin: > Hello HP, > > Wednesday, May 21, 2008, 8:11:56 PM, you wrote: > > Suppose p1, p2, p3 are 3 predicates > > that take an input -- say, a String. > > They return either (True, result) > > or False. > > impossible because these are different types :)) > > if they return Just result or Nothing - yes, use Maybe as monad: > > combine p1 p2 p3 x= do x1 <- p1 x > x2 <- p2 x1 > x3 <- p3 x2 > return x3 > > or shortly > > combine p1 p2 p3 x = p1 x >>= p2 >>= p3 Actually, (s)he wanted a sort of catch chain, so import Control.Monad -- for MonadPlus combine p1 p2 p3 x = p1 x `mplus` p2 x `mplus` p3 x or combine ps x = msum $ map ($ x) ps or just case p1 x of Just r -> return r Nothing -> case p2 x of Just r -> return r Nothing -> ... From cmb21 at kent.ac.uk Wed May 21 13:00:13 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed May 21 12:53:38 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: On Wed, 21 May 2008, HP Wei wrote: > > Suppose p1, p2, p3 are 3 predicates > that take an input -- say, a String. > They return either (True, result) > or False. > > I want to get an effect like in this expression: > > case p1 s of > (True, r) -> r > False -> case p2 s of > (True, r) -> r > False -> case p3 s of > (True, r) -> r > False -> none > > Is this a job for Maybe monad ? > How do I do that ? > I think this is a job for the Either monad: data Either a b = Left a | Right b case p1 s of (Left (True, r)) -> r (Right False) -> case p2 s of (Left (True, r)) -> r (Right False) -> case p3 s of (Left (True, r)) -> r (Right False) -> none So you wrap up your (Bool, result) type using Left, and your Bool type using Right. Regards, Chris. > Thanks > HP > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From cmb21 at kent.ac.uk Wed May 21 13:02:48 2008 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed May 21 12:56:09 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: On further thought, better to use the Maybe afterall. You can use Nothing to signify your False and Just to signify your result. case p1 s of Just result -> result Nothing -> case p2 s of ... That's probably more intuitive to what you were intending. Chris. On Wed, 21 May 2008, C.M.Brown wrote: > On Wed, 21 May 2008, HP Wei wrote: > > > > > Suppose p1, p2, p3 are 3 predicates > > that take an input -- say, a String. > > They return either (True, result) > > or False. > > > > I want to get an effect like in this expression: > > > > case p1 s of > > (True, r) -> r > > False -> case p2 s of > > (True, r) -> r > > False -> case p3 s of > > (True, r) -> r > > False -> none > > > > Is this a job for Maybe monad ? > > How do I do that ? > > > > I think this is a job for the Either monad: > > data Either a b = Left a | Right b > > case p1 s of > (Left (True, r)) -> r > (Right False) -> case p2 s of > (Left (True, r)) -> r > (Right False) -> case p3 s of > (Left (True, r)) -> r > (Right False) -> none > > So you wrap up your (Bool, result) type using Left, and your Bool type > using Right. > > Regards, > Chris. > > > > > > Thanks > > HP > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From hp at rentec.com Wed May 21 13:25:15 2008 From: hp at rentec.com (HP Wei) Date: Wed May 21 13:18:34 2008 Subject: how do I abstract this pattern ? In-Reply-To: References: Message-ID: Thanks to all who has replied in such a short time. >From your reponses, I looked at the definition of `mplus` Nothing `mplus` ys = ys xs `mplus` _ = xs It catches the essence of what I am trying to do! Later, if pn grows in number, I can scale up by using some-kind-of-zero with some higher order foldx-like functions. Thanks a lot, --hp On Wed, 21 May 2008, HP Wei wrote: > > Suppose p1, p2, p3 are 3 predicates > that take an input -- say, a String. > They return either (True, result) > or False. > > I want to get an effect like in this expression: > > case p1 s of > (True, r) -> r > False -> case p2 s of > (True, r) -> r > False -> case p3 s of > (True, r) -> r > False -> none > > Is this a job for Maybe monad ? > How do I do that ? > > Thanks > HP > From allbery at ece.cmu.edu Wed May 21 16:55:32 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 21 16:48:53 2008 Subject: how do I abstract this pattern ? In-Reply-To: <1453427852.20080521203142@gmail.com> References: <1453427852.20080521203142@gmail.com> Message-ID: <47041C0A-90E6-4FAA-8942-DFB342EE530A@ece.cmu.edu> On 2008 May 21, at 12:31, Bulat Ziganshin wrote: > Wednesday, May 21, 2008, 8:11:56 PM, you wrote: > >> Suppose p1, p2, p3 are 3 predicates >> that take an input -- say, a String. >> They return either (True, result) >> or False. > > if they return Just result or Nothing - yes, use Maybe as monad: > > combine p1 p2 p3 x= do x1 <- p1 x > x2 <- p2 x1 > x3 <- p3 x2 > return x3 S/He's not passing on r (the result), but s (the argument). Monad ((- >) r)? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From stefan at cs.uu.nl Thu May 22 07:40:37 2008 From: stefan at cs.uu.nl (Stefan Holdermans) Date: Thu May 22 07:33:55 2008 Subject: Type checker loops with innocent looking associated type synonym In-Reply-To: References: <86E628B8-F7D3-47C6-AF6D-9C59C8E0EA67@cs.uu.nl> Message-ID: <10993B3D-C6CB-4793-99E9-4A84B051B8BE@cs.uu.nl> Manuel, >> Should I report this a bug? Or is it perhaps already been taken >> care of in the head? > > Probably the latter. > > But really as, Bulat wrote, type families in 6.8 are unsupported. > Please test your code with a HEAD snapshot. If that goes wrong, a > bug report on Trac would be most appreciated. Indeed: no problem with yesterday's HEAD. Thanks, Stefan From donn at avvanta.com Thu May 22 12:09:51 2008 From: donn at avvanta.com (Donn Cave) Date: Thu May 22 12:03:01 2008 Subject: integer size on NetBSD amd64 Message-ID: <20080522090951.ba7247aa.donn@avvanta.com> I have been trying to get ghc working on the NetBSD AMD64 platform, and there seems to be a little problem with the integer size. With minInt and maxInt defined as they are in GHC/Base.lhs, ghc can't compile this file - it cranks away and just gets bigger until all the memory is gone. Base.lhs compiles right away if I reduce the size of minInt and maxInt by several bits - minInt = I# (-0x2000000000000000#) maxInt = I# 0x1FFFFFFFFFFFFFFF# -- minInt = I# (-0x8000000000000000#) -- maxInt = I# 0x7FFFFFFFFFFFFFFF# (... and it goes on to crash in GHC/Num.lhs.) So ... maybe somewhere in there, something isn't configured right for 64 bit integer arithmetic, even though the word size parameters in ghcautoconf.h look right? Anyone have an idea what to look for? The GHC version is 6.6.1. The .hc donor host is OpenBSD, gcc3 (NetBSD has gcc4.) The include files from NetBSD (DerivedConstants.h, GHCConstants.h, ghcautoconf.h) look fine, I just went back to the OpenBSD build to verify that they weren't changed during the build. The procedure I'm following is `Cross-compiling to produce an unregisterised GHC' http://hackage.haskell.org/trac/ghc/wiki/Building/Porting thanks! Donn Cave, donn@avvanta.com From Christian.Maeder at dfki.de Fri May 23 05:46:36 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri May 23 05:39:53 2008 Subject: 6.6.1 vs 6.8.2 --- Re: large binary footprint ? In-Reply-To: <20080507212022.GF5108@scytale.galois.com> References: <20080507212022.GF5108@scytale.galois.com> Message-ID: <4836927C.70008@dfki.de> Don Stewart wrote: > hp: >> I convinced myself that the ~500kbytes for the >> 'hello' code is 'correct' in version 6.6.1. >> [ The exact size on the platform mentioned below >> is 422k. ] >> >> Looks like version 6.8.2 blows up the binary code size >> significantly --- 3.9Mbytes vs 0.422Mbytes. >> >> Is this a known issue with 6.8.2 ? >> Is it a specific platform dependent issue --- i.e. >> does it occur on linux machines ?? I can confirm HP's code size. I've no idea what went wrong (or differently): -bash-3.00$ ls -l hello -rwxr-xr-x 1 maeder wimi 3907865 May 23 11:38 hello > That's platform dependent. It means on ghc 6.8.2 wasn't built with > split-objs enabled, so it includes a whole bunch of dead code > normally stripped out. > > Consult whoever built the ghc on your platform, to ensure > they know how to build with split objects. > > -- Don Object Splitting was enabled: -bash-3.00$ ll hello -rwxr-xr-x 1 maeder wimi 3907865 May 23 11:38 hello -bash-3.00$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.8.2") ,("Booter version","6.8.1") ,("Stage","2") ,("Interface file version","6") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("Win32 DLLs","") ,("RTS ways"," debug thr thr_p thr_debug") ,("Leading underscore","NO") ] Cheers Christian From bulat.ziganshin at gmail.com Fri May 23 16:15:38 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 23 16:11:38 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <1211572557.5824.542.camel@localhost> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <1832550999.20080523205602@gmail.com> <1211572557.5824.542.camel@localhost> Message-ID: <279581828.20080524001538@gmail.com> Hello Duncan, Friday, May 23, 2008, 11:55:57 PM, you wrote: >> > me too. btw, this already present in jhc. inlining doesn't work in any >> > complex case since recursive functions can't be inlined >> >> GHC inlines recursive functions, too, otherwise it could not turn 'foldl' >> and friends into plain machine loops. > As I understand it, if foldl was written in the standard directly way > then ghc would not inline it well, i'm not a True GHC Hacker ;) but i was bitten by this problem in 6.4. i had a lot of SPECIALIZE pragmas in Streams library exactly because INLINE doesn't help. actually, it even does things worser by disabling some other form of optimization, i don't remember which one i have proposal of inlining even recursive functions just for one level of recursion in order to allow to call here specialized version of function. what GHC HQ will say? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Fri May 23 16:19:42 2008 From: dons at galois.com (Don Stewart) Date: Fri May 23 16:12:56 2008 Subject: [Haskell-cafe] Announce: ghc-core, command line pager for reading GHC Core In-Reply-To: <279581828.20080524001538@gmail.com> References: <20080502014857.GA1722@scytale.galois.com> <404396ef0805020033q74dfbad4qfb5bf1a425c3fa03@mail.gmail.com> <1832550999.20080523205602@gmail.com> <1211572557.5824.542.camel@localhost> <279581828.20080524001538@gmail.com> Message-ID: <20080523201942.GG4034@scytale.galois.com> bulat.ziganshin: > Hello Duncan, > > Friday, May 23, 2008, 11:55:57 PM, you wrote: > > >> > me too. btw, this already present in jhc. inlining doesn't work in any > >> > complex case since recursive functions can't be inlined > >> > >> GHC inlines recursive functions, too, otherwise it could not turn 'foldl' > >> and friends into plain machine loops. > > > As I understand it, if foldl was written in the standard directly way > > then ghc would not inline it > > well, i'm not a True GHC Hacker ;) but i was bitten by this problem > in 6.4. i had a lot of SPECIALIZE pragmas in Streams library exactly > because INLINE doesn't help. actually, it even does things worser by > disabling some other form of optimization, i don't reme