RE: specialization using RULES
| The rules do not fire. They only seem to fire if the specialized | function is called directly, such as | | doSomethingWith ( zipWith (-) (u :: Vec Three Double) v ) That's probably because to fire distance must be inlined but sumV and mapV must not which is obviously a bit delicate. To do that you need fairly fine grain control over exactly when inlining takes place. That's what the [n] part of an INLINE pragma is for. Look in GHC.Base for examples. Don and Duncan are experts. I wish there was a more robust way to do this. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: too much let-floating
| No, I don't want to duplicate. But in my example the let var was only | used once, so there was no sharing problem. Not so in general -- floating outside a lambda that is called many times can dramatically increase sharing. You're right that all you want is to *forgo* an optimisation; but I want to avoid people complaining about lost optimisations! | In my original example, once we get to a later phase of compilation, the | let bound thing does get inlined again. Once the bind and write | functions get inlined, lots of case expressions appear and then it | becomes obvious that it'd be beneficial to inline, and ghc does so. And Hmm. Indeed, looking at it: lvl_s198 = write 1 (pokeWord8 0) I believe that there are no redexes there, correct? So we are gaining no sharing of work. GHC is simply avoiding an allocation, by floating to the top level, rather than actually avoiding work. Is that always so in the cases you are bothered about? That is, the annoying floating is saving allocation but not work? And GHC can see that? If so, perhaps we can make the first run of FloatOut not do allocation-saving. There's a second run later I think. You could have a go at this if you like. Look at SetLevels.lhs line 400. I think you might try something like replacing 'True' with: floatConsts env || not (exprIsCheap expr) The 'floatConsts' flag is False for the first run of FloatOut but True for the second. | So how about the idea of taking the rule pattern into account when | deciding to let-float That could be the next thing to try. I used to look at LHSs etc, but decided that it was not robust enough. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution
Hi Gregory, On Wed, May 30, 2007 at 05:56:31PM -0400, Gregory Wright wrote: On May 30, 2007, at 4:05 PM, Simon Marlow wrote: Gregory Wright wrote: I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64 at http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- freebsd.tar.bz2 Great, thanks! yay! Ian will supply a link from the download page in due course, I'm sure. Now done. I still owe you some source patches to make the compiler build out of the box. If 6.6.1 is the end of the line, would you prefer that these be against HEAD? Yup, HEAD is best. darcs send route (now possible, since darcs builds on x86_64)? darcs send is fine. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.6.1 on Debian Etch?
Hi, what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? -- Thanks, Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Prelude not in haskell98?
Hello, I am using GHC 6.6 and I am trying to build a library using Cabal. The library is written in Haskell'98 so I made the Cabal file depend only on the package haskell98. Unfortunately building the library fails with the following error: MyModule.hs:1:0: Failed to load interface for `Prelude': it is a member of package base, which is hidden The module MyModule does not have any imports (except for the implicitly imported Prelude). If I add an extra dependency on package base, then the library compiles. All this seems to indicate that the Prelude is not a part of the haskell98 package. Is this the case, and if so, is this intentional? It would be nice if we could create Cabal packages that explicitly indicate that the library depends only on Haskell 98 libraries. -Iavor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
On Tue, Jun 05, 2007 at 10:13:41PM +0200, Wagner Ferenc wrote: Hi, what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? Yes. Install the binary .tar.gz bundle *without creating a stub package* It installs in /usr/local, so dpkg must not know about it. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude not in haskell98?
Hi Iavor, All this seems to indicate that the Prelude is not a part of the haskell98 package. Is this the case, and if so, is this intentional? It would be nice if we could create Cabal packages that explicitly indicate that the library depends only on Haskell 98 libraries. Its true, and its intentional. The trend nowadays is to make programs depend only on base, not only on haskell98 - i.e. import System.Environment (and others) instead of System. hakell98 will be around forever, but base is the new standard libraries set. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude not in haskell98?
On Tue, Jun 05, 2007 at 11:23:57PM +0100, Neil Mitchell wrote: All this seems to indicate that the Prelude is not a part of the haskell98 package. Is this the case, and if so, is this intentional? It would be nice if we could create Cabal packages that explicitly indicate that the library depends only on Haskell 98 libraries. Its true, and its intentional. The trend nowadays is to make programs depend only on base, not only on haskell98 - i.e. import System.Environment (and others) instead of System. hakell98 will be around forever, but base is the new standard libraries set. Right, the problem is that if Prelude was in haskell98 then it wouldn't be possible to have a program that /didn't/ depend on haskell98 (short of -fno-implicit-prelude extensions, or having a Prelude in both (which would mean you couldn't depend on both base and haskell98)). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude not in haskell98?
On Wed, Jun 06, 2007 at 12:39:20AM +0100, Ian Lynagh wrote: On Tue, Jun 05, 2007 at 11:23:57PM +0100, Neil Mitchell wrote: All this seems to indicate that the Prelude is not a part of the haskell98 package. Is this the case, and if so, is this intentional? It would be nice if we could create Cabal packages that explicitly indicate that the library depends only on Haskell 98 libraries. Its true, and its intentional. The trend nowadays is to make programs depend only on base, not only on haskell98 - i.e. import System.Environment (and others) instead of System. hakell98 will be around forever, but base is the new standard libraries set. Right, the problem is that if Prelude was in haskell98 then it wouldn't be possible to have a program that /didn't/ depend on haskell98 (short of -fno-implicit-prelude extensions, or having a Prelude in both (which would mean you couldn't depend on both base and haskell98)). There's also a pragmatic reason. Currently it is impossible to have a cycle of module imports cross package boundaries; so if the Prelude was in haskell98, then (since the Prelude depends on non-haskell98 base modules for its implementation) *Nothing* in base could use the prelude. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude not in haskell98?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan O'Rear wrote: Right, the problem is that if Prelude was in haskell98 then it wouldn't be possible to have a program that /didn't/ depend on haskell98 (short of -fno-implicit-prelude extensions, or having a Prelude in both (which would mean you couldn't depend on both base and haskell98)). There's also a pragmatic reason. Currently it is impossible to have a cycle of module imports cross package boundaries; so if the Prelude was in haskell98, then (since the Prelude depends on non-haskell98 base modules for its implementation) *Nothing* in base could use the prelude. (Assuming haskell98 depends on base currently) It seems we would want haskell98 to re-export base's Prelude. It's just that that's not implemented in released-ghc package management code. Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZfpSHgcxvIWYTTURAhPvAJwIe+CTJnOBpOLQohbK+kC8Rg2XawCeK+E0 H8vIR1fCNZE9C2/dMLXLvQw= =aMyC -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
