From igloo at earth.li Sun Jul 1 08:47:32 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Jul 1 08:41:34 2007 Subject: readArray is faster than unsafeRead In-Reply-To: References: <465C3A74.4090004@ira.uka.de> Message-ID: <20070701124732.GA10607@matrix.chaos.earth.li> On Tue, May 29, 2007 at 02:42:22PM -0700, Scott Dillard wrote: > You're right. I broke them when experimenting to see where the cycles > were going. I've fixed them, but the other pair of functions, named > gaussElim2, were correct and the issue remains that unsafeRead appears > slower than readArray. Separating the functions into different executables and compiling with GHC 6.6 without profiling, the unsafe one is definitely faster: ./safe 45.73s user 0.06s system 96% cpu 47.238 total ./unsafe 6.65s user 0.02s system 91% cpu 7.295 total Thanks Ian From simonmarhaskell at gmail.com Mon Jul 2 05:18:18 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jul 2 05:12:23 2007 Subject: -keep-hc-files or -keep-hc-file? In-Reply-To: <20070630134310.GA18076@matrix.chaos.earth.li> References: <4682327E.1080705@tzi.de> <4683BBB7.80509@tzi.de> <20070630134310.GA18076@matrix.chaos.earth.li> Message-ID: <4688C2DA.6080701@gmail.com> Ian Lynagh wrote: > On Thu, Jun 28, 2007 at 03:46:31PM +0200, Christian Maeder wrote: >> Christian Maeder schrieb: >>> I'm currently confused if it must be plural or singular (or any) >>> >>> http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#keeping-intermediates >>> >>> shows plural options whereas >>> http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#id3131928 >>> >>> shows them in singular (except -keep-tmp-files) > > Well spotted; thanks for reporting it! > >> The plural options work! So flag-reference.html should be corrected. > > In actual fact the flag reference was exactly right, except the flags > could take any argument, which they then ignore (so the "s"s were being > treated as an argument when you gave the flags as plurals). > > This meant that things like "-keep-s-file=no" would also result in the > .s file being kept, so I've changed the code to accept only > -keep-foo (makes sense when using ghc -c) and -keep-foos (makes sense > when using ghc --make). -keep-tmp-files is still plural-only. > > Everything should be consistent now. Just FYI, historically, these flags were called -keep-hc-file-too, -keep-s-file-too, etc. When I rewrote the driver I made it ignore the suffix, so that I could shorten the flag names and keep backwards compatibility. I don't think anyone still uses the old names. Cheers, Simon From simonpj at microsoft.com Tue Jul 3 04:28:35 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 3 04:22:35 2007 Subject: Vote for GHC 6.8 bugs! Message-ID: Friends, We are gearing up towards at GHC 6.8 release. You can see details of what will be in it in the GHC status report for April http://hackage.haskell.org/trac/ghc/wiki/Status/April07. One symptom of the sharply-increased use of GHC is the sharply-increased number of bug reports and feature requests. We have no fewer than 200 milestoned for 6.8! You can see a summary here: http://hackage.haskell.org/trac/ghc/roadmap In reality we're unlikely to fix all 200, at least not without a lot of help from our friends. Inevitably, we have to prioritise. One way we do that is by using our (unreliable) perception of which bugs you (GHC's users) care about. This message is to invite you to improve the accuracy of this perception, by voting for the bugs you care about. We have just instituted a cheap-and-cheerful mechanism for voting. Each bug has a 'cc' field. To vote, just add your email address to the cc field! Better still, add a note to say why you care, and/or add a test case. We'll use the number of cc's (and an informal impression of any notes you've added) to guide our priorities. Adding yourself to the cc list means you'll get mail whenever anyone modifies the Trac report, which keeps you informed of what's going on. (You have to log in to edit Trac reports. Currently, new accounts are disabled for boring spammy reasons. That will be fixed when we upgrade Trac, but meanwhile, log in as guest, password guest.) It's not a perfect system, but we think it'll give useful extra guidance. So please go ahead and vote. But better still, help us fix bugs! GHC is open-source software, and it has a very large "surface area" (many platforms, many libraries, many features, documentation, tools, etc etc). Lots of people help make GHC good -- please join in (see the "Joining in" list in the GHC Wiki sidebar http://hackage.haskell.org/trac/ghc/wiki/) thanks Simon From srdjan.stipic at gmail.com Tue Jul 3 06:36:22 2007 From: srdjan.stipic at gmail.com (=?UTF-8?Q?Sr=C4=91an_Stipi=C4=87?=) Date: Tue Jul 3 06:30:17 2007 Subject: How to compile .hc files with gcc? Message-ID: <721db22f0707030336wb724ba8l901c676f8a545225@mail.gmail.com> I wanted to compile simple Haskell program (simple.hs) to .c and after that to target platform (x86). I did the following things: ghc -C simple.hs mv simple.hc simple.c gcc -c simple.c -I/usr/lib/ghc-6.6/include/ And I got the following error message: In file included from /usr/lib/ghc-6.6/include/Stg.h:148, from treci.c:3: /usr/lib/ghc-6.6/include/Regs.h:220: warning: call-clobbered register used for global register variable /usr/lib/ghc-6.6/include/Regs.h:226: warning: call-clobbered register used for global register variable /tmp/ccBtIPsT.s: Assembler messages: /tmp/ccBtIPsT.s:31: Error: junk at end of line, first unrecognized character is `-' /tmp/ccBtIPsT.s:63: Error: junk at end of line, first unrecognized character is `-' How to compile .hc files with gcc? Tnx, Srdjan From duncan.coutts at worc.ox.ac.uk Tue Jul 3 08:28:07 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Jul 3 08:21:52 2007 Subject: How to compile .hc files with gcc? In-Reply-To: <721db22f0707030336wb724ba8l901c676f8a545225@mail.gmail.com> References: <721db22f0707030336wb724ba8l901c676f8a545225@mail.gmail.com> Message-ID: <1183465687.6962.72.camel@localhost> On Tue, 2007-07-03 at 12:36 +0200, Sr?an Stipi? wrote: > I wanted to compile simple Haskell program (simple.hs) to .c and after > that to target platform (x86). > > I did the following things: > > ghc -C simple.hs > mv simple.hc simple.c > gcc -c simple.c -I/usr/lib/ghc-6.6/include/ > > And I got the following error message: [...] > How to compile .hc files with gcc? One way to find out is to ask ghc how it does it! :-) ghc -fvia-C -v -c simple.hs this will produce lots of output including the gcc command that ghc uses to compile the C code and then assemble it to a .o file. It's probably best however, just to use ghc to compile your .hs files to .o files, and especially to do the final link, since it does need quite a large set of gcc flags. Duncan From srdjan.stipic at gmail.com Tue Jul 3 08:31:09 2007 From: srdjan.stipic at gmail.com (=?UTF-8?Q?Sr=C4=91an_Stipi=C4=87?=) Date: Tue Jul 3 08:25:03 2007 Subject: How to compile .hc files with gcc? In-Reply-To: <1183465687.6962.72.camel@localhost> References: <721db22f0707030336wb724ba8l901c676f8a545225@mail.gmail.com> <1183465687.6962.72.camel@localhost> Message-ID: <721db22f0707030531g17020b3y1142a30ed166beab@mail.gmail.com> Thanks for the advice. Srdjan From tomasz.zielonka at gmail.com Tue Jul 3 08:49:29 2007 From: tomasz.zielonka at gmail.com (Tomasz Zielonka) Date: Tue Jul 3 08:43:28 2007 Subject: Vote for GHC 6.8 bugs! In-Reply-To: References: Message-ID: <20070703124929.GB21019@lambda> On Tue, Jul 03, 2007 at 09:28:35AM +0100, Simon Peyton-Jones wrote: > We have just instituted a cheap-and-cheerful mechanism for voting. > Each bug has a 'cc' field. To vote, just add your email address to > the cc field! How should we separate email addresses? Right now people use different characters: space, comma or semicolon. Best regards Tomek From simonmarhaskell at gmail.com Tue Jul 3 10:36:25 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Jul 3 10:30:24 2007 Subject: Vote for GHC 6.8 bugs! In-Reply-To: <20070703124929.GB21019@lambda> References: <20070703124929.GB21019@lambda> Message-ID: <468A5EE9.60102@gmail.com> Tomasz Zielonka wrote: > On Tue, Jul 03, 2007 at 09:28:35AM +0100, Simon Peyton-Jones wrote: >> We have just instituted a cheap-and-cheerful mechanism for voting. >> Each bug has a 'cc' field. To vote, just add your email address to >> the cc field! > > How should we separate email addresses? > Right now people use different characters: space, comma or semicolon. From a glance at the Trac code, I'd say comma or space, but not semicolon. Cheers, Smion From p.k.f.holzenspies at utwente.nl Wed Jul 4 04:33:25 2007 From: p.k.f.holzenspies at utwente.nl (Philip =?utf-8?B?Sy5GLiBIw7ZsemVuc3BpZXM=?=) Date: Wed Jul 4 04:27:18 2007 Subject: Need help understanding the Coverage Condition Message-ID: <20070704083325.GA28898@ewi708.cs.utwente.nl> L.S., I have difficulty understanding the Coverage Condition. Hopefully, someone has the time and is willing to explain this to me. Obviously, I went ahead and hacked together something horribly entangled, but I found a small example that already shows the behaviour I do not understand. Type-level addition of Church numerals: {- begin -} {-# OPTIONS -fglasgow-exts #-} data Z -- Zero data S x -- Successor of x class Add a b c | a b -> c instance Add Z q q instance Add p q r => (S p) q (S r) {- end -} The error GHCi produces is: Illegal instance declaration for `Add (S x) y (S z)' (the Coverage Condition fails for one of the functional dependencies; Use -fallow-undecidable-instances to permit this) In the instance declaration for `Add (S x) y (S z)' Failed, modules loaded: none. I checked the user guide (7.4.4.1) for criteria for functional dependencies and checked that I do not violate the assertions. I don't violate assertions 1a and 1b, but assertion 2 (the coverage condition) I have trouble reading: The coverage condition. For each functional dependency, tvc_left -> tvs_right, of the class, every type variable in S(tvs_right) must appear in S(tvs_left), where S is the substitution mapping each type variable in the class declaration to the corresponding type in the instance declaration. In my mind, in this case: tvs_left = {a,b} tvs_right = {c} S(tvs_left) = {p,q} S(tvs_right) = {r} What "occur in" means (mappings of type variables occurring in mappings of other type variables), I really don't quite understand. The example in the manual under 7.4.4.2, viz: instance Mul a b c => Mul a [b] [c] where x .*. v = map (x.*.) v seams related, but unfortunately is not elaborated upon beyond "[it] does not obey the coverage condition" The suggested flag to "allow undecidable instances" is throwing me off, since it seems very unambiguously decidable to me. Regards, Philip From bertram.felgenhauer at googlemail.com Wed Jul 4 11:23:04 2007 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Wed Jul 4 11:17:01 2007 Subject: Need help understanding the Coverage Condition In-Reply-To: <20070704083325.GA28898@ewi708.cs.utwente.nl> References: <20070704083325.GA28898@ewi708.cs.utwente.nl> Message-ID: <20070704152304.GA4637@zombie.inf.tu-dresden.de> Philip K.F. H??lzenspies wrote: [snip] > {- begin -} > {-# OPTIONS -fglasgow-exts #-} > > data Z -- Zero > data S x -- Successor of x > > class Add a b c | a b -> c > instance Add Z q q > instance Add p q r => (S p) q (S r) > > {- end -} [snip] > The coverage condition. For each functional dependency, tvc_left -> > tvs_right, of the class, every type variable in S(tvs_right) must > appear in S(tvs_left), where S is the substitution mapping each type > variable in the class declaration to the corresponding type in the > instance declaration. > > In my mind, in this case: > tvs_left = {a,b} > tvs_right = {c} > S(tvs_left) = {p,q} > S(tvs_right) = {r} > What "occur in" means (mappings of type variables occurring in > mappings of other type variables), I really don't quite understand. > The example in the manual under 7.4.4.2, viz: It's subset check. S(tvs_right) must be a subset of S(tvs_left) which is clearly not the case. The condition is sufficient (but not necessary) to let type checking terminate. > The suggested flag to "allow undecidable instances" is throwing me > off, since it seems very unambiguously decidable to me. Ambiguity is not the issue here, ensuring termination is. The consequence of using -fundecidable-instances is that there is no a priori guarantee that type checking will terminate. [*] If it does terminate, the final result will be correct. HTH, Bertram [*] In your particular example termination will probably be guaranteed by a structural property: In deriving Add (S x) y (S z) the compiler will look for an instance Add x y z where all three type terms are smaller. The nice thing about the coverage condition is save and can be checked easily per instance. From simonpj at microsoft.com Wed Jul 4 12:35:44 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Jul 4 12:29:37 2007 Subject: Need help understanding the Coverage Condition In-Reply-To: <20070704083325.GA28898@ewi708.cs.utwente.nl> References: <20070704083325.GA28898@ewi708.cs.utwente.nl> Message-ID: Philip Have you read "Understanding functional dependencies via Constraint Handling Rules"? http://research.microsoft.com/~simonpj/papers/fd-chr If not, I urge you to consider doing so. It goes into the whole thing in great detail. I'm submerged for the next 3 weeks, though others may be able to help you. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Philip K.F. H?lzenspies | Sent: 04 July 2007 09:33 | To: glasgow-haskell-users@haskell.org | Subject: Need help understanding the Coverage Condition | | L.S., | | I have difficulty understanding the Coverage Condition. From p.k.f.holzenspies at utwente.nl Wed Jul 4 14:21:21 2007 From: p.k.f.holzenspies at utwente.nl (Philip =?utf-8?B?Sy5GLiBIw7ZsemVuc3BpZXM=?=) Date: Wed Jul 4 14:15:12 2007 Subject: Need help understanding the Coverage Condition In-Reply-To: References: <20070704083325.GA28898@ewi708.cs.utwente.nl> Message-ID: <20070704182120.GA1241@ewi708.cs.utwente.nl> On Wed, Jul 04, 2007 at 05:35:44PM +0100, Simon Peyton-Jones wrote: > Have you read "Understanding functional dependencies via Constraint > Handling Rules"? > http://research.microsoft.com/~simonpj/papers/fd-chr > > If not, I urge you to consider doing so. It goes into the whole > thing in great detail. I'm submerged for the next 3 weeks, though > others may be able to help you. Simon, I knew I had a "to read" scribbled down in the back of my mind somewhere, but it had slipped out. I will read that paper and see how far I get (although it still seems that it should be possible to relax the covering condition somewhat, being that the example I gave is decidable on paper ;) ) Thank you for the reference. Regards, Philip From Christian.Maeder at dfki.de Thu Jul 5 05:15:03 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jul 5 05:08:56 2007 Subject: ghc 6.6 Debian packages Message-ID: <468CB697.90901@dfki.de> Hi, our developers that have a debian system (i.e Ubuntu) and want to compile our sources with ghc complain that they have to install many extra library packages one after another. Compiling fails at various stages due to missing packages. Is there no way to provide all the extra libs in one debian package for ghc? Cheers Christian ii libghc6-fgl-dev 5.3-3 Haskell graph library for GHC ii libghc6-haskell-src-dev 1.0-3 Haskell module for manipulating Haskell sour ii libghc6-html-dev 1.0-3 Haskell html library for GHC ii libghc6-hunit-dev 1.1-3 Haskell unit testing framework for GHC ii libghc6-mtl-dev 1.0-3 Haskell monad transformer library for GHC ii libghc6-network-dev 2.0-3 Haskell network library for GHC ii libghc6-quickcheck-dev 1.0-3 Haskell automatic testing library for GHC From mdanish at andrew.cmu.edu Thu Jul 5 12:11:32 2007 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Thu Jul 5 12:05:22 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <468CB697.90901@dfki.de> References: <468CB697.90901@dfki.de> Message-ID: <20070705161132.GK2031@mapcar.org> On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: > Hi, > > our developers that have a debian system (i.e Ubuntu) and want to > compile our sources with ghc complain that they have to install many > extra library packages one after another. > > Compiling fails at various stages due to missing packages. > > Is there no way to provide all the extra libs in one debian package for ghc? It may be possible to create a "package" which depends on all normal "extras" but that seems counter-productive. What is the problem with asking them to run the command: apt-get install libghc6-fgl-dev libghc6-haskell-src-dev libghc6-html-dev libghc6-hunit-dev libghc6-mtl-dev libghc6-network-dev libghc6-quickcheck-dev which installs everything and doesn't saddle them with a ton of unnecessary other files? -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org From Christian.Maeder at dfki.de Thu Jul 5 13:07:21 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Jul 5 13:01:15 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <20070705161132.GK2031@mapcar.org> References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> Message-ID: <468D2549.6060503@dfki.de> Matthew Danish schrieb: > What is the problem with asking them to run the command: > > apt-get install libghc6-fgl-dev libghc6-haskell-src-dev libghc6-html-dev libghc6-hunit-dev libghc6-mtl-dev libghc6-network-dev libghc6-quickcheck-dev > > which installs everything and doesn't saddle them with a ton of > unnecessary other files? The problem (for me) is/was to actually find the list of libs that are needed. I rather recommend to get a complete binary-dist from the ghc home page (instead of diving into the various package management tools). Christian From nr at eecs.harvard.edu Thu Jul 5 15:04:06 2007 From: nr at eecs.harvard.edu (Norman Ramsey) Date: Thu Jul 5 14:57:56 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <20070705161132.GK2031@mapcar.org> (sfid-H20070705-121153-+040.30-1@spamfilter.osbf.lua) References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> (sfid-H20070705-121153-+040.30-1@spamfilter.osbf.lua) Message-ID: <20070705190409.A0202788072@labrador.eecs.harvard.edu> > On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: > > Hi, > > > > our developers that have a debian system (i.e Ubuntu) and want to > > compile our sources with ghc complain that they have to install many > > extra library packages one after another. > > > > Compiling fails at various stages due to missing packages. > > > > Is there no way to provide all the extra libs in one debian package for > > ghc? > > It may be possible to create a "package" which depends on all normal > "extras" but that seems counter-productive. As a Debian user who frequently operates disconnected from the network, I have to say I have found such 'extras' packages highly productive---the loss of disk space is more than compensated for by the ability to continue working during a long plane flight, because packages I didn't know I needed are already installed on my system. I would welcome a virtual package to pull in all things ghc-6.6. Norman From igloo at earth.li Thu Jul 5 18:12:16 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 5 18:06:21 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <20070705190409.A0202788072@labrador.eecs.harvard.edu> References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> <20070705190409.A0202788072@labrador.eecs.harvard.edu> Message-ID: <20070705221216.GA23751@matrix.chaos.earth.li> On Thu, Jul 05, 2007 at 03:04:06PM -0400, Norman Ramsey wrote: > > As a Debian user who frequently operates disconnected from the > network, I have to say I have found such 'extras' packages highly > productive---the loss of disk space is more than compensated for by > the ability to continue working during a long plane flight, because > packages I didn't know I needed are already installed on my system. > > I would welcome a virtual package to pull in all things ghc-6.6. If you are using Debian etch then you can do apt-get install "libghc6-.*-dev" to install all GHC 6 libraries. There isn't such an easy way to install just those (somewhat arbitrarily) defined to be extralibs, though. Thanks Ian From john at repetae.net Thu Jul 5 19:24:48 2007 From: john at repetae.net (John Meacham) Date: Thu Jul 5 19:18:35 2007 Subject: RTS/Garbage Collector idea In-Reply-To: <467681D2.10004@gmail.com> References: <4676625B.7080102@charter.net> <467681D2.10004@gmail.com> Message-ID: <20070705232448.GA5652@momenergy.repetae.net> On Mon, Jun 18, 2007 at 02:00:02PM +0100, Simon Marlow wrote: > Isaac Dupree wrote: > > >I was thinking, since we have a copying garbage collector that reassigns > >all pointers anyway, could we detect the "identical" heap objects and > >for each set of identical ones, have all thunks that pointed to any of > >them, now point to the single one that is created in the target space? > > I think what you're proposing is often called "hash consing", except that > hash-consing is usually done at construction time, you want to do it at GC > time. > > My take is it would only be worthwhile if there was a *lot* of sharing to > be gained by doing it, and in most cases there wouldn't be. This is just a > guess based on my experience poking around in the heap though - feel free > to try it out and prove me wrong :-) it might be worthwhile to do in a couple specific cases, like a cache of small Ints or the ascii characters. John -- John Meacham - ?repetae.net?john? From stefanor at cox.net Thu Jul 5 19:44:54 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Jul 5 19:38:43 2007 Subject: RTS/Garbage Collector idea In-Reply-To: <20070705232448.GA5652@momenergy.repetae.net> References: <4676625B.7080102@charter.net> <467681D2.10004@gmail.com> <20070705232448.GA5652@momenergy.repetae.net> Message-ID: <20070705234453.GA4947@localhost.localdomain> On Thu, Jul 05, 2007 at 04:24:48PM -0700, John Meacham wrote: > On Mon, Jun 18, 2007 at 02:00:02PM +0100, Simon Marlow wrote: > > Isaac Dupree wrote: > > > > >I was thinking, since we have a copying garbage collector that reassigns > > >all pointers anyway, could we detect the "identical" heap objects and > > >for each set of identical ones, have all thunks that pointed to any of > > >them, now point to the single one that is created in the target space? > > > > I think what you're proposing is often called "hash consing", except that > > hash-consing is usually done at construction time, you want to do it at GC > > time. > > > > My take is it would only be worthwhile if there was a *lot* of sharing to > > be gained by doing it, and in most cases there wouldn't be. This is just a > > guess based on my experience poking around in the heap though - feel free > > to try it out and prove me wrong :-) > > it might be worthwhile to do in a couple specific cases, like a cache of > small Ints or the ascii characters. Incidentally, GHC already does this, and has for so long that the optimization was described in section 7.3 of the original paper "Implementing lazy functional languages on stock hardware: The spineless tagless G-machine" (SPJ, 1992, JFP) (pages 48-49 on at least one copy). Stefan From dm.maillists at gmail.com Thu Jul 5 20:12:49 2007 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Thu Jul 5 20:06:39 2007 Subject: RTS/Garbage Collector idea In-Reply-To: <467681D2.10004@gmail.com> References: <4676625B.7080102@charter.net> <467681D2.10004@gmail.com> Message-ID: <200707061212.49913.dm.maillists@gmail.com> On Tuesday 19 June 2007 01:00, Simon Marlow wrote: > Isaac Dupree wrote: > > I was thinking, since we have a copying garbage collector that reassigns > > all pointers anyway, could we detect the "identical" heap objects and > > for each set of identical ones, have all thunks that pointed to any of > > them, now point to the single one that is created in the target space? > > I think what you're proposing is often called "hash consing", except that > hash-consing is usually done at construction time, you want to do it at GC > time. > > My take is it would only be worthwhile if there was a *lot* of sharing to > be gained by doing it, and in most cases there wouldn't be. This is just a > guess based on my experience poking around in the heap though - feel free > to try it out and prove me wrong :-) Presumably it's possible to do a piece-meal app-level hash consing of values by defining an appropriate identity memoisation. Though maybe the optimiser is so cunning it figures out you're returning an equal value and skips it. It'd be nice if there were system wide hash consing memoisations that could be called when substantial sharing was anticipated. Maybe an easy approximation is keeping your String trie, or whatever, in a global IORef. Or what about hash consing after an equality test? Less opportunity but perhaps less cost. Daniel From Christian.Maeder at dfki.de Fri Jul 6 03:46:39 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 6 03:40:44 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <20070705221216.GA23751@matrix.chaos.earth.li> References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> <20070705190409.A0202788072@labrador.eecs.harvard.edu> <20070705221216.GA23751@matrix.chaos.earth.li> Message-ID: <468DF35F.40206@dfki.de> Ian Lynagh schrieb: > If you are using Debian etch then you can do > > apt-get install "libghc6-.*-dev" > > to install all GHC 6 libraries. There isn't such an easy way to install > just those (somewhat arbitrarily) defined to be extralibs, though. Could someone list the available packages (and its versions)? Are there plans to provide also ghc-6.6.1 debian packages? I think ghc-6.6.1 provides new time and filepath packages. Thanks Christian From bulat.ziganshin at gmail.com Fri Jul 6 04:24:45 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jul 6 04:21:32 2007 Subject: RTS/Garbage Collector idea In-Reply-To: <200707061212.49913.dm.maillists@gmail.com> References: <4676625B.7080102@charter.net> <467681D2.10004@gmail.com> <200707061212.49913.dm.maillists@gmail.com> Message-ID: <186435185.20070706122445@gmail.com> Hello Daniel, it seems like a good proposal for general-purpose library Friday, July 6, 2007, 4:12:49 AM, you wrote: > Presumably it's possible to do a piece-meal app-level hash consing of values > by defining an appropriate identity memoisation. Though maybe the optimiser > is so cunning it figures out you're returning an equal value and skips it. > It'd be nice if there were system wide hash consing memoisations that could be > called when substantial sharing was anticipated. Maybe an easy approximation > is keeping your String trie, or whatever, in a global IORef. > Or what about hash consing after an equality test? Less opportunity but > perhaps less cost. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Fri Jul 6 06:26:00 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jul 6 06:19:45 2007 Subject: Prefix form of unboxed tuple Message-ID: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> Hi, The following works fine: ghci -fglasgow-exts Prelude> case (# 1 , 2 #) of (# a , b #) -> error $ show (a,b) *** Exception: (1,2) You might expect there to be a prefix form of the unboxed tuple: Prelude> case (#,#) 1 2 of (# a , b #) -> error $ show (a,b) :1:7: parse error on input `,' But there isn't. I've added special code into the Yhc code generator to deal with this particular constructor, so it no longer effects me. Thanks Neil From igloo at earth.li Fri Jul 6 07:17:16 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Jul 6 07:11:09 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <468DF35F.40206@dfki.de> References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> <20070705190409.A0202788072@labrador.eecs.harvard.edu> <20070705221216.GA23751@matrix.chaos.earth.li> <468DF35F.40206@dfki.de> Message-ID: <20070706111716.GA27724@matrix.chaos.earth.li> On Fri, Jul 06, 2007 at 09:46:39AM +0200, Christian Maeder wrote: > Ian Lynagh schrieb: > > If you are using Debian etch then you can do > > > > apt-get install "libghc6-.*-dev" > > > > to install all GHC 6 libraries. There isn't such an easy way to install > > just those (somewhat arbitrarily) defined to be extralibs, though. > > Could someone list the available packages (and its versions)? In Debian Etch (stable)? http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libghc6&searchon=names&subword=1&version=stable&release=all > Are there plans to provide also ghc-6.6.1 debian packages? At some point, but there are more pressing things to do first. > I think ghc-6.6.1 provides new time and filepath packages. time was a 6.6 extralib and is in stable. (I don't know off the top of my head what differences there were between the versions that came with 6.6 and 6.6.1). filepath wasn't an extralib, but is in stable nonetheless. Thanks Ian From john at repetae.net Fri Jul 6 08:08:22 2007 From: john at repetae.net (John Meacham) Date: Fri Jul 6 08:02:08 2007 Subject: Prefix form of unboxed tuple In-Reply-To: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> References: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> Message-ID: <20070706120822.GI300@momenergy.repetae.net> On Fri, Jul 06, 2007 at 11:26:00AM +0100, Neil Mitchell wrote: > ghci -fglasgow-exts > Prelude> case (# 1 , 2 #) of (# a , b #) -> error $ show (a,b) > *** Exception: (1,2) > > You might expect there to be a prefix form of the unboxed tuple: > > Prelude> case (#,#) 1 2 of (# a , b #) -> error $ show (a,b) > :1:7: parse error on input `,' > > But there isn't. I've added special code into the Yhc code generator > to deal with this particular constructor, so it no longer effects me. > Well, what would the type of (#,#) be? unboxed tuples can hold both boxed and unboxed values, so some sort of kind polymorphism would be needed to type the prefix form properly. John -- John Meacham - ?repetae.net?john? From isaacdupree at charter.net Fri Jul 6 09:03:40 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jul 6 08:55:38 2007 Subject: Prefix form of unboxed tuple In-Reply-To: <20070706120822.GI300@momenergy.repetae.net> References: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> <20070706120822.GI300@momenergy.repetae.net> Message-ID: <468E3DAC.9040601@charter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Meacham wrote: > On Fri, Jul 06, 2007 at 11:26:00AM +0100, Neil Mitchell wrote: >> ghci -fglasgow-exts >> Prelude> case (# 1 , 2 #) of (# a , b #) -> error $ show (a,b) >> *** Exception: (1,2) >> >> You might expect there to be a prefix form of the unboxed tuple: >> >> Prelude> case (#,#) 1 2 of (# a , b #) -> error $ show (a,b) >> :1:7: parse error on input `,' >> >> But there isn't. I've added special code into the Yhc code generator >> to deal with this particular constructor, so it no longer effects me. >> > > Well, what would the type of (#,#) be? unboxed tuples can hold both > boxed and unboxed values, so some sort of kind polymorphism would be > needed to type the prefix form properly. In GHC, some special functions have kind polymorphism error :: forall a:?. String -> a (->) :: ?? -> ? -> * (\(x::t) -> ...) Here t::?? (i.e. not unboxed tuple) (and "But the 'real' type of error is: forall bv. forall a:Type bv. String -> a ") Or just saying it's illegal to partially apply (#,#) - which I believe is how (some of) GHC's primops work. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjj2rHgcxvIWYTTURAp03AJ4/kgTzuN6PHp5QFTOQBKJIKa8QtQCeLvjm hh9TO2NDFzZ2N+FYsgOORGU= =6GJm -----END PGP SIGNATURE----- From stoller at cs.sunysb.edu Fri Jul 6 09:59:41 2007 From: stoller at cs.sunysb.edu (Scott Stoller) Date: Fri Jul 6 09:53:29 2007 Subject: problem compiling an older Haskell program with GHC 6.6.1 Message-ID: <18062.19149.277506.801396@gargle.gargle.HOWL> hi, I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). in case anyone else wants to try it, I put the paradox source code at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz in the Makefile, I deleted "-package lang" from HFLAGS, and added "-v" to it. then I typed "make". I got the following error message: Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1 Using package config file: /usr/local/lib/ghc-6.6.1/package.conf wired-in package base mapped to base-2.1.1 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.1 Hsc static flags: -static Created temporary directory: /tmp/ghc13306_0 *** Chasing dependencies: Set.hs:26:7: Could not find module `Data.FiniteMap': locations searched: Data/FiniteMap.hs Data/FiniteMap.lhs *** Deleting temp files: Deleting: /tmp/ghc13306_0/ghc13306_0.dep *** Deleting temp dirs: Deleting: /tmp/ghc13306_0 make: *** [depend.mak] Error 1 is this a backwards-compatibility issue between GHC 6.6.1 and older versions of GHC? is there a simple workaround? I can't easily use an older version of GHC, because I don't see binary distributions of older versions of GHC for Solaris x86. any advice would be greatly appreciated. best regards, scott From waldmann at imn.htwk-leipzig.de Fri Jul 6 10:03:20 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Fri Jul 6 09:57:07 2007 Subject: problem compiling an older Haskell program with GHC 6.6.1 In-Reply-To: <18062.19149.277506.801396@gargle.gargle.HOWL> References: <18062.19149.277506.801396@gargle.gargle.HOWL> Message-ID: <468E4BA8.7050407@imn.htwk-leipzig.de> > Could not find module `Data.FiniteMap': > is this a backwards-compatibility issue between GHC 6.6.1 and older > versions of GHC? the module has just vanished from libraries. > is there a simple workaround? ugly, but workable: http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/lib/Autolib/Data/Map.hs?rev=1.6 best regards, j.w. From ndmitchell at gmail.com Fri Jul 6 10:14:39 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jul 6 10:08:28 2007 Subject: problem compiling an older Haskell program with GHC 6.6.1 In-Reply-To: <468E4BA8.7050407@imn.htwk-leipzig.de> References: <18062.19149.277506.801396@gargle.gargle.HOWL> <468E4BA8.7050407@imn.htwk-leipzig.de> Message-ID: <404396ef0707060714w4fc63dc3u8bcd1df1697d14c6@mail.gmail.com> Hi > http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/lib/Autolib/Data/Map.hs?rev=1.6 Or easier: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap-0.1 Thanks Neil From ketil at ii.uib.no Fri Jul 6 02:36:28 2007 From: ketil at ii.uib.no (Ketil Malde) Date: Fri Jul 6 10:10:46 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <20070705161132.GK2031@mapcar.org> References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> Message-ID: <1183703788.6064.7.camel@nmd9999> On Thu, 2007-07-05 at 12:11 -0400, Matthew Danish wrote: > On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: > > Is there no way to provide all the extra libs in one debian package for ghc? > It may be possible to create a "package" which depends on all normal > "extras" but that seems counter-productive. Au contraire - I think that is a great way to go about it, and it is how a lot of things get done. Meta-packages include desktop environments (e.g. KDE and Gnome) and the Linux kernel (e.g. linux-generic). -k From duncan.coutts at worc.ox.ac.uk Fri Jul 6 10:39:26 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jul 6 10:32:57 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <1183703788.6064.7.camel@nmd9999> References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> <1183703788.6064.7.camel@nmd9999> Message-ID: <1183732766.5807.88.camel@localhost> On Fri, 2007-07-06 at 08:36 +0200, Ketil Malde wrote: > On Thu, 2007-07-05 at 12:11 -0400, Matthew Danish wrote: > > On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote: > > > > Is there no way to provide all the extra libs in one debian package for ghc? > > > It may be possible to create a "package" which depends on all normal > > "extras" but that seems counter-productive. > > Au contraire - I think that is a great way to go about it, and it is how > a lot of things get done. Meta-packages include desktop environments > (e.g. KDE and Gnome) and the Linux kernel (e.g. linux-generic). However those projects clearly define which components make up the whole. We do not. There are the core packages that come with ghc and then there are all the other packages you can find on hackage. The 'extra' packages is just a bunch that used to be distributed with ghc. They're not intended to be canonical as far as I know. My understanding is that that 'extra' tarball is just a transitional thing provided for convenience until hackage gets up to speed. If people want to go and define some standard distribution of packages then that's another matter, but that's something that should be driven centrally rather than each of the various distro maintainers picking some arbitrary set of packages. Duncan (wearing his Gentoo packager hat) From simonpj at microsoft.com Fri Jul 6 10:57:26 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jul 6 10:51:25 2007 Subject: Prefix form of unboxed tuple In-Reply-To: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> References: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> Message-ID: | You might expect there to be a prefix form of the unboxed tuple: | | Prelude> case (#,#) 1 2 of (# a , b #) -> error $ show (a,b) | :1:7: parse error on input `,' | | But there isn't. No real reason why not. If you write foo :: a -> b -> (# a,b #) foo x y = (# x, y #) then foo should work just fine. So what you want needs two things: * We would have to define a collection of such functions in the Prelude (see Data.Tuple, for the (,,,,) functions). * We'd have to do is to make the parser understand '(#,,,#)'. Do add a feature request if you like. (And/or implement it!) It'd be a good "rounding out" thing. Another feature I'd like is for unboxed tuples to be more first class. For example, we don't currently allow f :: (# a, b #) -> ... But there's no real reason why not; we could transform them away just before code generation. That would eliminate all special cases for unboxed tuples, except the constraints that apply to all unboxed types (notably: you can't instantiate a type variable with an unboxed type; unboxed types are strict). If you add a feature request, add that too! Simon From ndmitchell at gmail.com Fri Jul 6 11:07:27 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jul 6 11:01:11 2007 Subject: Prefix form of unboxed tuple In-Reply-To: References: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> Message-ID: <404396ef0707060807y44f1ca78ue8723017e7acd3cc@mail.gmail.com> Hi > No real reason why not. If you write > > foo :: a -> b -> (# a,b #) > foo x y = (# x, y #) > > then foo should work just fine. So what you want needs two things: > > Do add a feature request if you like. (And/or implement it!) It'd be a good "rounding out" thing. > > Another feature I'd like is for unboxed tuples to be more first class. For example, we don't currently allow > f :: (# a, b #) -> ... Ah, this tripped me up for a long time this afternoon. The error message I was getting was not particularly helpful - I discovered that by putting this type in a constructor and projecting into and out of the constructor things worked. I never realise that the unboxed tuple in a type signature just didn't work. Thanks Neil From bulat.ziganshin at gmail.com Fri Jul 6 11:21:40 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jul 6 11:18:36 2007 Subject: Prefix form of unboxed tuple In-Reply-To: References: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> Message-ID: <584190118.20070706192140@gmail.com> Hello Simon, Friday, July 6, 2007, 6:57:26 PM, you wrote: > Another feature I'd like is for unboxed tuples to be more first > class. For example, we don't currently allow > f :: (# a, b #) -> ... one particular feature i wanted in my fast io/serialization libs is ability to return unboxed tuple from IO action. is this also possible? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From simonpj at microsoft.com Fri Jul 6 11:26:27 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jul 6 11:20:11 2007 Subject: Prefix form of unboxed tuple In-Reply-To: <584190118.20070706192140@gmail.com> References: <404396ef0707060326t199afafahe466aa70680c8016@mail.gmail.com> <584190118.20070706192140@gmail.com> Message-ID: | one particular feature i wanted in my fast io/serialization libs is | ability to return unboxed tuple from IO action. is this also possible? No -- that's an example of instantiating a polymorphic type with an unboxed one. Sorry. S From p.tanski at gmail.com Fri Jul 6 11:42:16 2007 From: p.tanski at gmail.com (Peter Tanski) Date: Fri Jul 6 11:36:21 2007 Subject: problem compiling an older Haskell program with GHC 6.6.1 Message-ID: <02D0EA35-F115-4E67-9401-1C900D78E68F@gmail.com> On Fri, 6 Jul 2007 09:59:41 -0400 Scott Stoller wrote: > I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, > with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). > > > Set.hs:26:7: > Could not find module `Data.FiniteMap': > locations searched: > Data/FiniteMap.hs > Data/FiniteMap.lhs > *** Deleting temp files: > Deleting: /tmp/ghc13306_0/ghc13306_0.dep > *** Deleting temp dirs: > Deleting: /tmp/ghc13306_0 > make: *** [depend.mak] Error 1 > > is this a backwards-compatibility issue between GHC 6.6.1 and older > versions of GHC? is there a simple workaround? The problem is that the Data.FiniteMap library has been deprecated and renamed to Data.Map. See http://www.haskell.org/ghc/dist/current/ docs/libraries/base/Data-Map.html . The solution is to go through paradox and change references to Data.FiniteMap to Data.Map and, especially, to check that functions from Data.FiniteMap now have the form of Data.Map. Changing the functions should not be too hard: mostly swapping variables around. You may also run into namespace collision problems with Data.List (GHC will alert you), in which case: import Data.Map as Map import Data.List as List and for each function that collided, such as map or fold, specify which one you are using: Data.map ... List.map ... Otherwise you should be fine. The change from Data.FiniteMap to Data.Map has been around for a little while now but there are still quite a few old libraries kicking around that use FiniteMap and need to be updated. Cheers, Pete From bulat.ziganshin at gmail.com Fri Jul 6 14:52:04 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Jul 6 14:48:44 2007 Subject: [GHC] #1338: base package breakup In-Reply-To: <105.44ab72c904c3ae77c82810a0daa66ded@localhost> References: <096.a316e36c559577ba370116e1c71cfdd4@localhost> <105.44ab72c904c3ae77c82810a0daa66ded@localhost> Message-ID: <1748127427.20070706225204@gmail.com> Hello GHC, Friday, July 6, 2007, 10:04:05 PM, you wrote: > #1338: base package breakup > Not clear what to do with these: > Control.Applicative > Data.Foldable, Data.Traversable > Data.Map, Data.IntMap, Data.Set, Data.IntSet > Data.Sequence, Data.Tree > Data.HashTable > Data.Graph > ---> new package collections? containers? or split further? > (dep. on array, generics, concurrent) package named Collections already exists. one possible way of splitting these modules would be separation of Control.Applicative, Data.Foldable, Data.Traversable while changing names of established modules and adding new hierarchy roots aren't good ideas, may be it will better to rename them to Class.* or even Concept.*? Monads, Data/Typeable, i/o Streams and other classes may be moved to the same place. the intention is to split packages to those defining concepts (classes) and whose implementing them, with multiple packages that implements these concepts > Data.Array.* > --> new package array (maybe; I'm slightly dubious here) > (dep. on concurrent for Data.Array.Diff) definitely! > Needs the above to happen first: > Data.Generics.* > --> generics (maybe; Data class is defined for everything and is > derivable) how about using standalone deriving in this package? derive Data for Int, Handle.... > Needs Data.Array.Diff to move out of base first: > Control.Concurrent.*, System.Timeout > --> new package concurrent how about renaming System.Timeout to Control.Concurrent.Timeout ? > Needs concurrent to be done first: > Data.Unique > --> new package unique (dep on concurrent) may be it's better to consider it as one more multi-threading service and move it into concurrent package? separate package for 60 lines-long module doesn't seem like a good approach > Will happen soon: > Data.ByteString.* > --> bytestring (dep. on base, generics, array) > Other modules we might move: > Text.Printf, Data.Monoid, System.CPUTime afaiu, Data.Monoid should go together with Foldable and so on? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From chuckanut at gmail.com Fri Jul 6 18:34:43 2007 From: chuckanut at gmail.com (chuckanut) Date: Fri Jul 6 18:28:27 2007 Subject: rpm for RHEL4 Message-ID: <412ad0330707061534x11169f5fv6af312c8950fee1a@mail.gmail.com> Hi, I am looking for an rpm for Red Hat enterprise linux 4 for x86_64. Can anyone point me to such an rpm? I don't think the FC5 binary will work on EL4. Thanks From stoller at cs.sunysb.edu Sat Jul 7 15:59:48 2007 From: stoller at cs.sunysb.edu (Scott Stoller) Date: Sat Jul 7 15:53:29 2007 Subject: problem compiling an older Haskell program with GHC 6.6.1 Message-ID: <18063.61620.50920.329205@gargle.gargle.HOWL> hi, I really appreciate the amazingly fast and helpful feedback to my previous message. that problem (FiniteMap not found) is solved. but a new problem came up... I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). now I get the error Data.hs:760:20: Not in scope: 'bounds' Data.hs is one of the files in the program. here is the nearby code: updateTable :: Hash a => a -> IO b -> Table a b -> IO b updateTable x my (MkTable ref) = do MkHTab n arr <- readIORef ref let (_,size) = bounds arr hashx = hash x i = hashx `mod` size ... in case it's helpful, the entire paradox source code is at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz just delete "-package lang" from the Makefile before running "make". any advice would be greatly appreciated. best regards, scott From stefanor at cox.net Sat Jul 7 16:02:47 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Jul 7 15:56:29 2007 Subject: problem compiling an older Haskell program with GHC 6.6.1 In-Reply-To: <18063.61620.50920.329205@gargle.gargle.HOWL> References: <18063.61620.50920.329205@gargle.gargle.HOWL> Message-ID: <20070707200247.GA5855@localhost.localdomain> On Sat, Jul 07, 2007 at 03:59:48PM -0400, Scott Stoller wrote: > hi, > > I really appreciate the amazingly fast and helpful feedback to my previous > message. that problem (FiniteMap not found) is solved. but a new problem > came up... > > I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, > with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). > > now I get the error > > Data.hs:760:20: Not in scope: 'bounds' > > Data.hs is one of the files in the program. here is the nearby code: > > updateTable :: Hash a => a -> IO b -> Table a b -> IO b > updateTable x my (MkTable ref) = > do MkHTab n arr <- readIORef ref > let (_,size) = bounds arr > hashx = hash x > i = hashx `mod` size > ... > > in case it's helpful, the entire paradox source code is at > http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz > just delete "-package lang" from the Makefile before running "make". Bounds was removed in 6.4.x to allow for dynamically sized arrays; it should work as: updateTable :: Hash a => a -> IO b -> Table a b -> IO b updateTable x my (MkTable ref) = do MkHTab n arr <- readIORef ref (_,size) <- getBounds arr let hashx = hash x i = hashx `mod` size Stefan From stoller at cs.sunysb.edu Sat Jul 7 22:53:17 2007 From: stoller at cs.sunysb.edu (Scott Stoller) Date: Sat Jul 7 22:46:59 2007 Subject: type error when compiling an older Haskell program In-Reply-To: <18063.61620.50920.329205@gargle.gargle.HOWL> References: <18063.61620.50920.329205@gargle.gargle.HOWL> Message-ID: <18064.20893.419019.636866@gargle.gargle.HOWL> hi, thanks to Stefan, I am past the second problem in compiling this program (needed to change 'bounds' to 'getBounds'). now I get a more intimidating error message... I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1. I get the intimidating error message shown below. I would appreciate any advice about how to fix this. I am guessing that the problem might be a change in the type of some library function. best regards, scott p.s. the file causing the error is in the paradox source code at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz Building paradox (release) Compiling: AnalysisTypes.hs Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1 Using package config file: /usr/local/lib/ghc-6.6.1/package.conf wired-in package base mapped to base-2.1.1 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.1 Hsc static flags: -fauto-sccs-on-all-toplevs -static Created temporary directory: /tmp/ghc835_0 *** Checking old interface for main:AnalysisTypes: *** Parser: *** Renamer/typechecker: AnalysisTypes.hs:135:2: Inferred type is less polymorphic than expected Quantified type variable `s' is mentioned in the environment: m :: forall b. STRef s Int -> STRef s ((:=>) Symbol [TypeId s]) -> STRef s ((:=>) Symbol ([TypeId s], TypeId s)) -> STRef s ((:=>) Symbol (TypeId s)) -> (String -> ST s b) -> (a -> ST s b) -> ST s b (bound at AnalysisTypes.hs:284:6) In the first argument of `runST', namely `(do idfs <- newSTRef 0 preds <- newSTRef empty funs <- newSTRef empty vars <- newSTRef empty m idfs preds funs vars (\ s -> return (Left s)) (\ _ -> do ps' <- readSTRef preds fs' <- readSTRef funs ps <- sequence ([... | (p, ts') <- ...]) fs <- sequence ([... | (f, (ts', t')) <- ...]) typeIds' <- sequence ([... | t' <- ...]) let typeIds = ... names = ... typesAndTypeIds = ... types = ... typeIdToType = ... typeOfId tid = ... predTable = ... funTable = ... typeOfPred Equal = ... typeOfPred (p ::- _) = ... typeOfFun (f ::- _) = ... trans c = ... where ... return (Right (types, trans))))' In the expression: runST (do idfs <- newSTRef 0 preds <- newSTRef empty funs <- newSTRef empty vars <- newSTRef empty m idfs preds funs vars (\ s -> return (Left s)) (\ _ -> do ps' <- readSTRef preds fs' <- readSTRef funs ps <- sequence ([... | (p, ts') <- ...]) fs <- sequence ([... | (f, (ts', t')) <- ...]) typeIds' <- sequence ([... | t' <- ...]) let typeIds = ... names = ... typesAndTypeIds = ... types = ... typeIdToType = ... typeOfId tid = ... predTable = ... funTable = ... typeOfPred Equal = ... typeOfPred (p ::- _) = ... typeOfFun (f ::- _) = ... trans c = ... where ... return (Right (types, trans)))) In the definition of `runT': runT tm = runST (do idfs <- newSTRef 0 preds <- newSTRef empty funs <- newSTRef empty vars <- newSTRef empty m idfs preds funs vars (\ s -> return (Left s)) (\ _ -> do ps' <- ... fs' <- ... ps <- ... fs <- ... typeIds' <- ... let ... ...)) where MkT m = tm *** Deleting temp files: Deleting: /tmp/ghc835_0/ghc835_0.hc Warning: deleting non-existent /tmp/ghc835_0/ghc835_0.hc *** Deleting temp dirs: Deleting: /tmp/ghc835_0 make: *** [AnalysisTypes.o] Error 1 From stefanor at cox.net Sat Jul 7 23:17:51 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Jul 7 23:11:34 2007 Subject: type error when compiling an older Haskell program In-Reply-To: <18064.20893.419019.636866@gargle.gargle.HOWL> References: <18063.61620.50920.329205@gargle.gargle.HOWL> <18064.20893.419019.636866@gargle.gargle.HOWL> Message-ID: <20070708031751.GA7142@localhost.localdomain> On Sat, Jul 07, 2007 at 10:53:17PM -0400, Scott Stoller wrote: > hi, > > thanks to Stefan, I am past the second problem in compiling this program > (needed to change 'bounds' to 'getBounds'). now I get a more intimidating > error message... > > I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with > GHC 6.6.1. I get the intimidating error message shown below. I would > appreciate any advice about how to fix this. I am guessing that the > problem might be a change in the type of some library function. > > best regards, > scott > > p.s. the file causing the error is in the paradox source code at > http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz Add {-# OPTIONS_GHC -fno-mono-pat-binds #-} You are the fourth person to discover monomorphic pattern bindings :) As an experiment, the GHC team has changed GHC to make pattern bindings (like MkT m = tm) default to only produce values usable at one type. The full generality of Haskell-98's rules complicated the implementation, and the idea was that if sufficiently few people complained, the next version of Haskell could use simpler rules. (at least that's how *I* remember the explanation.) Another workaround is to do it with an explicit unwrap: where m = case tm of MkT m -> m instead of where MkT m = tm Stefan From amir.aharoni at gmail.com Sun Jul 8 08:12:27 2007 From: amir.aharoni at gmail.com (Amir E. Aharoni) Date: Sun Jul 8 08:06:10 2007 Subject: using Haskell readline package on Cygwin Message-ID: <97f280ea0707080512q270fa208v1ac2014d5cac396f@mail.gmail.com> Hi, I'm trying to build pugs ( http://www.pugscode.org/ ) on Cygwin. I have GHC 6.6.1 (installed from MSI). Pugs build routine tries to look for the readline package and fails: $ ghc-pkg describe readline ghc-pkg.exe: cannot find package readline I have GNU readline installed as a Cygwin package, but it looks like the readline package, which appears to be standard on other GHC-supported platforms, is not installed with GHC on Windows. This problem is mentioned in the GHC FAQ ( http://tinyurl.com/2lyjno ) but there is no solution; maybe there was supposed to be a link, but it is not there now. Is it possible to install the readline package manually? Thanks in advance. (Please excuse my cluelessness - i'm a GHC newbie.) -- Amir Elisha Aharoni my band: http://www.myspace.com/tzabari/ my blog: http://aharoni.wordpress.com/ From amir.aharoni at gmail.com Sun Jul 8 11:16:32 2007 From: amir.aharoni at gmail.com (Amir E. Aharoni) Date: Sun Jul 8 11:10:14 2007 Subject: using Haskell readline package on Cygwin In-Reply-To: <97f280ea0707080512q270fa208v1ac2014d5cac396f@mail.gmail.com> References: <97f280ea0707080512q270fa208v1ac2014d5cac396f@mail.gmail.com> Message-ID: <97f280ea0707080816h79a350d2vd6c4a8ea8fee28aa@mail.gmail.com> (Sorry if you received this twice. There was some problem with my mailer.) Hi, I'm trying to build pugs ( http://www.pugscode.org/ ) on Cygwin. I have GHC 6.6.1 (installed from MSI). Pugs build routine tries to look for the readline package and fails: $ ghc-pkg describe readline ghc-pkg.exe: cannot find package readline I have GNU readline installed as a Cygwin package, but it looks like the readline package, which appears to be standard on other GHC-supported platforms, is not installed with GHC on Windows. This problem is mentioned in the GHC FAQ ( http://tinyurl.com/2lyjno ) but there is no solution; maybe there was supposed to be a link, but it is not there now. Is it possible to install the readline package manually? Thanks in advance. (Please excuse my cluelessness - i'm a GHC newbie.) -- Amir Elisha Aharoni my band: http://www.myspace.com/tzabari/ my blog: http://aharoni.wordpress.com/ From chuckanut at gmail.com Sun Jul 8 22:21:20 2007 From: chuckanut at gmail.com (chuckanut) Date: Sun Jul 8 22:14:57 2007 Subject: rpm for RHEL4 In-Reply-To: References: <412ad0330707061534x11169f5fv6af312c8950fee1a@mail.gmail.com> Message-ID: <412ad0330707081921k3ac6bd98j8d1b833dbed2131@mail.gmail.com> Thanks very much! I am just replying to the list so that someone else can take advantage of your work. On 7/7/07, Ronald Cole wrote: > I posted that I had ported the Fedora Core RPMs to RHEL4 and RHEL5 for both > i386 and x86_64 and was making them available from my site. I also asked > for it to be announced on the "distribution packages" page of haskell.org, > but that request seems to have fallen on deaf ears. > > Help yourself to my RPM packages at > . > > > On 7/6/07, chuckanut wrote: > > > > Hi, > > > > I am looking for an rpm for Red Hat enterprise linux 4 for x86_64. > > Can anyone point me to such an rpm? I don't think the FC5 binary will > > work on EL4. > > > > Thanks > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users@haskell.org > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > From simonpj at microsoft.com Mon Jul 9 03:51:26 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Jul 9 03:45:04 2007 Subject: type error when compiling an older Haskell program In-Reply-To: <20070708031751.GA7142@localhost.localdomain> References: <18063.61620.50920.329205@gargle.gargle.HOWL> <18064.20893.419019.636866@gargle.gargle.HOWL> <20070708031751.GA7142@localhost.localdomain> Message-ID: | Add {-# OPTIONS_GHC -fno-mono-pat-binds #-} | | You are the fourth person to discover monomorphic pattern bindings :) Yes, the details are here http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindings If you could snip out the code that gave rise to the error, I'll add it to that wiki page. (There are four other examples there, one from Koen which might perhaps be essentially the same thing.) thanks Stefan for identifying this Simon From Christian.Maeder at dfki.de Mon Jul 9 07:20:41 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Jul 9 07:14:11 2007 Subject: haskell's prefix exprs Message-ID: <46921A09.7080108@dfki.de> Hi, I would like haskell to accept the following (currently illegal) expressions as syntactically valid prefix applications: f = id \ _ -> [] g = id let x = [] in x h = id case [] of [] -> [] i = id do [] j = id if True then [] else [] The rational is that expressions starting with a keyword should extend as far as possible (to the right and over several lines within their layout). In this case the above right hand sides (rhs) are unique juxtapositions of two expressions. (This extension should of course apply to more than two expressions, i. e. "f a do []") Furthermore the above rhs are all valid if written as infix expressions: f = id $ \ _ -> [] g = id $ let x = [] in x h = id $ case [] of [] -> [] i = id $ do [] j = id $ if True then [] else [] (In fact, maybe for haskell' "$" could be changed to a keyword.) Does this pose any problems that I haven't considered? I think only more (and shorter) illegal haskell programs will become legal. Cheers Christian Maybe someone else can work out the details for Haskell's grammar From ndmitchell at gmail.com Mon Jul 9 18:13:34 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jul 9 18:07:11 2007 Subject: Unexpected boxing in generated code Message-ID: <404396ef0707091513g19d9bda5u5d246c6a94c1823f@mail.gmail.com> Hi, I've got an inner loop that I think I can see is strict in the Int argument being passed around, but that GHC 6.6.1 isn't unboxing. In the following example both functions take a GHC.Base.Int, which I think should be an Int#. Rec { f60_rS5 :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int [GlobalId] [Arity 2 NoCafRefs Str: DmdType LL] f60_rS5 = \ (v1_aWH :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWI :: GHC.Base.Int) -> case $wccall_r2kv v1_aWH of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> case ds1_d1V3 of wild1_X2L { __DEFAULT -> f60_rS5 ds_d1V4 v2_aWI; (-1) -> v2_aWI; 10 -> f561_r2kx ds_d1V4 v2_aWI } } f561_r2kx :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int [GlobalId] [Arity 2 NoCafRefs Str: DmdType LL] f561_r2kx = \ (v1_aWm :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWn :: GHC.Base.Int) -> case $wccall_r2kv v1_aWm of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> case ds1_d1V3 of wild1_X2P { __DEFAULT -> case v2_aWn of wild2_a2du { GHC.Base.I# x_a2dw -> case wild1_X2P of wild3_X35 { __DEFAULT -> f60_rS5 ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)); 10 -> f561_r2kx ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)) } }; (-1) -> v2_aWn } } end Rec } This code comes from a line counting program, I have attached the entire source. My character counting program does infer the correct strictness, although that is based on a single self-recursive function. The largest obvious difference is that the strictness depends on the two functions which call each other - does this impeed GHC's strictness analysis? Thanks Neil -------------- next part -------------- A non-text attachment was scrubbed... Name: 4.hs Type: application/octet-stream Size: 11869 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070709/6060e02a/4-0001.obj From brianh at metamilk.com Tue Jul 10 06:52:05 2007 From: brianh at metamilk.com (Brian Hulley) Date: Tue Jul 10 06:45:23 2007 Subject: haskell's prefix exprs In-Reply-To: <46921A09.7080108@dfki.de> References: <46921A09.7080108@dfki.de> Message-ID: <469364D5.1040401@metamilk.com> Christian Maeder wrote: > Hi, > > I would like haskell to accept the following (currently illegal) > expressions as syntactically valid prefix applications: > > f = id \ _ -> [] > g = id let x = [] in x > h = id case [] of [] -> [] > i = id do [] > j = id if True then [] else [] > > The rational is that expressions starting with a keyword should extend > as far as possible (to the right and over several lines within their > layout). > On page 15/16 of the H98 report I think this could be achieved by: exp10 ::= fexp fexp ::= [fexp] keyexp keyexp ::= \ apat ... -> exp | let ... | ... | aexp > (In fact, maybe for haskell' "$" could be changed to a keyword.) > Alternatively the # symbol could be removed from the pool of symbol chars and used to construct syntactic sugar so you could use f = id #$ \_ -> [] to mean exactly f = id (\_ -> []) I think when the idea of $ arose originally people didn't at that time know about the many cases where the use of $ is not semantically equivalent to explict brackets, since this knowledge probably only arose later with the introduction of rank-n polymorphism. (Of course the need for #$ would be fixed with impredicative types as in MLF.) Best regards, Brian. From simonpj at microsoft.com Tue Jul 10 07:23:05 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 10 07:16:38 2007 Subject: Unexpected boxing in generated code In-Reply-To: <404396ef0707091513g19d9bda5u5d246c6a94c1823f@mail.gmail.com> References: <404396ef0707091513g19d9bda5u5d246c6a94c1823f@mail.gmail.com> Message-ID: Very curious. It does indeed look as though the strictness analyser is confused; but it should certainly not be confused by mutual recursion. I'll definitely look into it. But don't hold your breath -- it's a very busy fortnight. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Neil Mitchell | Sent: 09 July 2007 23:14 | To: glasgow-haskell-users@haskell.org | Subject: Unexpected boxing in generated code | | Hi, | | I've got an inner loop that I think I can see is strict in the Int | argument being passed around, but that GHC 6.6.1 isn't unboxing. In | the following example both functions take a GHC.Base.Int, which I | think should be an Int#. | | Rec { | f60_rS5 :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int | [GlobalId] | [Arity 2 | NoCafRefs | Str: DmdType LL] | f60_rS5 = | \ (v1_aWH :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWI :: GHC.Base.Int) -> | case $wccall_r2kv v1_aWH of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> | case ds1_d1V3 of wild1_X2L { | __DEFAULT -> f60_rS5 ds_d1V4 v2_aWI; | (-1) -> v2_aWI; | 10 -> f561_r2kx ds_d1V4 v2_aWI | } | } | f561_r2kx :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int | [GlobalId] | [Arity 2 | NoCafRefs | Str: DmdType LL] | f561_r2kx = | \ (v1_aWm :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWn :: GHC.Base.Int) -> | case $wccall_r2kv v1_aWm of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> | case ds1_d1V3 of wild1_X2P { | __DEFAULT -> | case v2_aWn of wild2_a2du { GHC.Base.I# x_a2dw -> | case wild1_X2P of wild3_X35 { | __DEFAULT -> f60_rS5 ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)); | 10 -> f561_r2kx ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)) | } | }; | (-1) -> v2_aWn | } | } | end Rec } | | This code comes from a line counting program, I have attached the | entire source. My character counting program does infer the correct | strictness, although that is based on a single self-recursive | function. The largest obvious difference is that the strictness | depends on the two functions which call each other - does this impeed | GHC's strictness analysis? | | Thanks | | Neil From Christian.Maeder at dfki.de Tue Jul 10 08:26:40 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Jul 10 08:20:07 2007 Subject: haskell's prefix exprs In-Reply-To: <469364D5.1040401@metamilk.com> References: <46921A09.7080108@dfki.de> <469364D5.1040401@metamilk.com> Message-ID: <46937B00.9040905@dfki.de> Brian Hulley schrieb: > Christian Maeder wrote: >> (In fact, maybe for haskell' "$" could be changed to a keyword.) >> > > Alternatively the # symbol could be removed from the pool of symbol > chars and used to construct syntactic sugar so you could use > > f = id #$ \_ -> [] > > to mean exactly > > f = id (\_ -> []) For this case "#$" would not be needed when you could write: f = id \ _ -> [] A keyword "#$", if one really wanted it, would make sense to replace the infix application "id $ g x" with (the prefix expr) "id #$ g x", though. Cheers Christian From stoller at cs.sunysb.edu Tue Jul 10 14:48:10 2007 From: stoller at cs.sunysb.edu (Scott Stoller) Date: Tue Jul 10 14:41:46 2007 Subject: type error when compiling an older Haskell program In-Reply-To: References: <18063.61620.50920.329205@gargle.gargle.HOWL> <18064.20893.419019.636866@gargle.gargle.HOWL> <20070708031751.GA7142@localhost.localdomain> Message-ID: <18067.54378.609696.267079@gargle.gargle.HOWL> Simon Peyton-Jones writes: > | Add {-# OPTIONS_GHC -fno-mono-pat-binds #-} > | > | You are the fourth person to discover monomorphic pattern bindings :) > > Yes, the details are here > http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindings > > If you could snip out the code that gave rise to the error, I'll add it > to that wiki page. (There are four other examples there, one from Koen > which might perhaps be essentially the same thing.) it looks like that example from Koen (one of the authors of Paradox) is essentially the same as this one, as you guessed. If you'd like to add this code anyway, let me know. or perhaps it would be more appropriate to ask Koen, since it's his code. best regards, scott From Christian.Maeder at dfki.de Wed Jul 11 05:35:31 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Jul 11 05:28:54 2007 Subject: ghc 6.6 Debian packages In-Reply-To: <20070706111716.GA27724@matrix.chaos.earth.li> References: <468CB697.90901@dfki.de> <20070705161132.GK2031@mapcar.org> <20070705190409.A0202788072@labrador.eecs.harvard.edu> <20070705221216.GA23751@matrix.chaos.earth.li> <468DF35F.40206@dfki.de> <20070706111716.GA27724@matrix.chaos.earth.li> Message-ID: <4694A463.8050704@dfki.de> Ian Lynagh schrieb: > On Fri, Jul 06, 2007 at 09:46:39AM +0200, Christian Maeder wrote: >> Ian Lynagh schrieb: >>> If you are using Debian etch then you can do >>> >>> apt-get install "libghc6-.*-dev" >>> >>> to install all GHC 6 libraries. There isn't such an easy way to install >>> just those (somewhat arbitrarily) defined to be extralibs, though. >> Could someone list the available packages (and its versions)? > > In Debian Etch (stable)? > > http://packages.debian.org/cgi-bin/search_packages.pl?keywords=libghc6&searchon=names&subword=1&version=stable&release=all That's an impressive matrix of libraries and supported architectures. Loading all 46 libraries may be overkill for us. Furthermore we additionally need to install hxt, Shellac and Shellac-readline (and we use a slightly modified HTTP package that's used by hxt) Appart from the "(somewhat arbitrarily) defined" extralibs we need HaXml-1.13.2 and WashNGo (or "wash"). (We do not need all extralibs, though, i.e. OpenAL) Cheers Christian From dherman at ccs.neu.edu Wed Jul 11 10:25:38 2007 From: dherman at ccs.neu.edu (Dave Herman) Date: Wed Jul 11 10:19:14 2007 Subject: strange overlapping instance error Message-ID: <4694E862.1020601@ccs.neu.edu> I'm a little mystified by an overlapping instance error I'm getting from GHC (I'm using v6.6.1 in Windows). Here's a simple test case that demonstrates the type error: ----- {-# OPTIONS_GHC -fglasgow-exts #-} module Overlap where class Needle a instance Needle String class Needle b => Haystack a b where find :: a -> [b] instance Needle a => Haystack a a where find a = [a] instance Haystack a b => Haystack [a] b where find xs = concatMap find xs data Tree = Leaf String | Node [Tree] instance Haystack Tree String where find (Leaf s) = find s find (Node ss) = concatMap find ss ----- The error is: overlap.hs:21:18: Overlapping instances for Haystack String String arising from use of `find' at overlap.hs:21:18-23 Matching instances: instance (Needle a) => Haystack a a -- Defined at overlap.hs:11:0 instance (Haystack a b) => Haystack [a] b -- Defined at overlap.hs:14:0 In the expression: find s In the definition of `find': find (Leaf s) = find s In the definition for method `find' Now, I understand that String is [Char], but since the proposition (Haystack Char String) is not true, I don't understand why the type checker is claiming that the second instance declaration matches. Thanks, Dave From haskell at list.mightyreason.com Wed Jul 11 11:00:26 2007 From: haskell at list.mightyreason.com (haskell@list.mightyreason.com) Date: Wed Jul 11 10:54:00 2007 Subject: strange overlapping instance error In-Reply-To: <4694E862.1020601@ccs.neu.edu> References: <4694E862.1020601@ccs.neu.edu> Message-ID: <4694F08A.4060301@list.mightyreason.com> Dave Herman wrote: > I'm a little mystified by an overlapping instance error I'm getting from > GHC (I'm using v6.6.1 in Windows). Here's a simple test case that > demonstrates the type error: > > ----- > > {-# OPTIONS_GHC -fglasgow-exts #-} > module Overlap where > > class Needle a > > instance Needle String > > class Needle b => Haystack a b where > find :: a -> [b] > > instance Needle a => Haystack a a where > find a = [a] > > instance Haystack a b => Haystack [a] b where > find xs = concatMap find xs > > data Tree = Leaf String > | Node [Tree] > > instance Haystack Tree String where > find (Leaf s) = find s > find (Node ss) = concatMap find ss > > ----- > > The error is: > > overlap.hs:21:18: > Overlapping instances for Haystack String String > arising from use of `find' at overlap.hs:21:18-23 > Matching instances: > instance (Needle a) => Haystack a a -- Defined at overlap.hs:11:0 > instance (Haystack a b) => Haystack [a] b > -- Defined at overlap.hs:14:0 > In the expression: find s > In the definition of `find': find (Leaf s) = find s > In the definition for method `find' > > Now, I understand that String is [Char], but since the proposition > (Haystack Char String) is not true, I don't understand why the type > checker is claiming that the second instance declaration matches. > The type checker does not look at the contexts such as your (Haystack a b =>) when choosing an instance. After it chooses an instance it will look at the context for that instance. -- Chris From golubovsky at gmail.com Sun Jul 15 23:38:00 2007 From: golubovsky at gmail.com (Dimitry Golubovsky) Date: Sun Jul 15 23:31:14 2007 Subject: Why hide Distribution.Compat.FilePath, or what to use instead? Message-ID: Hi, I'm trying to bring HSFFIG in order and make it work with GHC 6.6 and the modern package structure. I have found out that the Distribution.Compat.FilePath module (which used to be System.FilePath in its former life) is hidden: programs/ffipkg.hs:11:7: Could not find module `Distribution.Compat.FilePath': it is hidden (in package Cabal-1.1.6.2) I cannot use the new FilePath package because it does not have function like exeExtension. Other functions (splitFileExt, parseSearchPath, joinFileName, join FileExt) probably have their analogs in the new package. What else can I use for exeExtension? Thanks. -- Dimitry Golubovsky Anywhere on the Web From mnislaih at gmail.com Mon Jul 16 03:10:47 2007 From: mnislaih at gmail.com (Pepe Iborra) Date: Mon Jul 16 03:04:04 2007 Subject: Why hide Distribution.Compat.FilePath, or what to use instead? In-Reply-To: References: Message-ID: Hi Dimitry, you don't want to use Distribution.Compat.FilePath, it is not there anymore in future versions of Cabal, starting with 1.1.7. In my experience, the only things that you will miss in filepath are those exeExtension, dllExtension... functions. It may be reasonable to import those from Compat.FilePath if you want, because they are kept (in another module I believe) in Cabal 1.1.7. Or better, update to Cabal 1.1.7 and import theM from the right module To unhide the module, you need to list Cabal as a dependency in the Cabal descriptor. Cheers pepe On 16/07/2007, at 5:38, Dimitry Golubovsky wrote: > Hi, > > I'm trying to bring HSFFIG in order and make it work with GHC 6.6 and > the modern package structure. I have found out that the > Distribution.Compat.FilePath module (which used to be System.FilePath > in its former life) is hidden: > > programs/ffipkg.hs:11:7: > Could not find module `Distribution.Compat.FilePath': > it is hidden (in package Cabal-1.1.6.2) > > I cannot use the new FilePath package because it does not have > function like exeExtension. > > Other functions (splitFileExt, parseSearchPath, joinFileName, join > FileExt) probably have their analogs in the new package. What else can > I use for exeExtension? > > Thanks. > > -- > Dimitry Golubovsky > > Anywhere on the Web > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From wangqj at cpit.com.cn Tue Jul 17 03:40:42 2007 From: wangqj at cpit.com.cn (=?gb2312?B?zfXH5b78?=) Date: Tue Jul 17 03:33:00 2007 Subject: haskell for web In-Reply-To: References: Message-ID: <44F1DCCDD544D34C9107869794D8D0DD02D00208@ptmail.putian.com> help=20 haskell for web code Powered by MessageSoft SMG=20 SPAM, virus-free and secure email From Alistair_Bayley at invescoperpetual.co.uk Tue Jul 17 03:48:05 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Tue Jul 17 03:41:26 2007 Subject: haskell for web In-Reply-To: <44F1DCCDD544D34C9107869794D8D0DD02D00208@ptmail.putian.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA901BDFB58@GBLONXMB02.corp.amvescap.net> PiBGcm9tOiBnbGFzZ293LWhhc2tlbGwtdXNlcnMtYm91bmNlc0BoYXNrZWxsLm9yZyAKPiBbbWFp bHRvOmdsYXNnb3ctaGFza2VsbC11c2Vycy1ib3VuY2VzQGhhc2tlbGwub3JnXSBPbiBCZWhhbGYg T2YgPz8/Cj4gCj4gaGVscCAKPiBoYXNrZWxsIGZvciB3ZWIgY29kZQoKCmh0dHA6Ly93d3cuaGFz a2VsbC5vcmcvaGFza2VsbHdpa2kvQXBwbGljYXRpb25zX2FuZF9saWJyYXJpZXMvV2ViX3Byb2dy YW1taW5nCgpUcnkgYSBmZXcgb2YgdGhlc2Ugb3V0ICh3aGF0ZXZlciBtZWV0cyB5b3VyIG5lZWRz KS4gRm9yIHdlYiBhcHBzIFdBU0ggYW5kIEhBcHBTIHNlZW0gcG9wdWxhci4gRmVlbCBmcmVlIHRv IGFzayB0aGUgaGFza2VsbC1jYWaopiBsaXN0IGZvciBmdXJ0aGVyIGhlbHAuCgpBbGlzdGFpcgoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgpDb25maWRlbnRpYWxpdHkgTm90ZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1lc3NhZ2UsCmFuZCBhbnkgYXR0YWNobWVudHMsIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBhbmQvb3IgcHJpdmlsZWdlZAptYXRlcmlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgcGVyc29uKHMpIG9yIGVudGl0eSB0bwp3aGljaCBpdCBpcyBhZGRyZXNzZWQuIEFueSBy ZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0aW9uLApvciB0YWtpbmcgb2YgYW55IGFj dGlvbiBpbiByZWxpYW5jZSB1cG9uIHRoaXMgaW5mb3JtYXRpb24gYnkKcGVyc29ucyBvciBlbnRp dGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgaXMKcHJvaGliaXRlZC4g SWYgeW91IHJlY2VpdmVkIHRoaXMgaW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IHRoZQpzZW5kZXIg YW5kIGRlbGV0ZSB0aGUgbWF0ZXJpYWwgZnJvbSBhbnkgY29tcHV0ZXIuCioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From igloo at earth.li Thu Jul 19 10:36:54 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 19 10:29:56 2007 Subject: rpm for RHEL4 In-Reply-To: <412ad0330707081921k3ac6bd98j8d1b833dbed2131@mail.gmail.com> References: <412ad0330707061534x11169f5fv6af312c8950fee1a@mail.gmail.com> <412ad0330707081921k3ac6bd98j8d1b833dbed2131@mail.gmail.com> Message-ID: <20070719143654.GA30911@matrix.chaos.earth.li> On Sun, Jul 08, 2007 at 07:21:20PM -0700, chuckanut wrote: > > On 7/7/07, Ronald Cole wrote: > > > >. I've now added these to the GHC download page. Thanks! Ian From ronald.cole at gmail.com Thu Jul 19 19:22:16 2007 From: ronald.cole at gmail.com (Ronald Cole) Date: Thu Jul 19 19:15:18 2007 Subject: rpm for RHEL4 In-Reply-To: <20070719143654.GA30911@matrix.chaos.earth.li> References: <412ad0330707061534x11169f5fv6af312c8950fee1a@mail.gmail.com> <412ad0330707081921k3ac6bd98j8d1b833dbed2131@mail.gmail.com> <20070719143654.GA30911@matrix.chaos.earth.li> Message-ID: Thanks, Ian! Should I have expected to see them show up at < http://www.haskell.org/ghc/distribution_packages.html> by now? On 7/19/07, Ian Lynagh wrote: > > On Sun, Jul 08, 2007 at 07:21:20PM -0700, chuckanut wrote: > > > > On 7/7/07, Ronald Cole wrote: > > > > > >. > > I've now added these to the GHC download page. Thanks! > > > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070719/e1e45ea2/attachment.htm From igloo at earth.li Thu Jul 19 19:50:51 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 19 19:43:53 2007 Subject: rpm for RHEL4 In-Reply-To: References: <412ad0330707061534x11169f5fv6af312c8950fee1a@mail.gmail.com> <412ad0330707081921k3ac6bd98j8d1b833dbed2131@mail.gmail.com> <20070719143654.GA30911@matrix.chaos.earth.li> Message-ID: <20070719235051.GA12381@matrix.chaos.earth.li> Hi Ronald, On Thu, Jul 19, 2007 at 04:22:16PM -0700, Ronald Cole wrote: > Thanks, Ian! Should I have expected to see them show up at < > http://www.haskell.org/ghc/distribution_packages.html> by now? They're here: http://www.haskell.org/ghc/download_ghc_661.html#rhel The distribution_packages page is really just pointers to the standard place for various OSes which include GHC packages. e.g. for RHEL, a pointer to, and a brief explanation on how to install from, something like CentOS would probably go on the distribution_packages page. I guess we could have it point to http://forte-intl.com/~ronald/haskell/ghc/ if you plan to keep making GHC builds available from there. Thanks Ian From marco-oweber at gmx.de Sat Jul 21 10:25:58 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Jul 21 10:19:09 2007 Subject: ghc-pkg: can't unregister - not found - describe works? Message-ID: <20070721142558.GJ23433@gmx.de> marc@localhost /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1 unregister wx ghc-pkg: cannot find package wx marc@localhost /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1 describe wx name: wx version: 0.10.1 license: AllRightsReserved [...] What does happen here? ghc-pkg-wrapper is just a simple script defining GHC_PACKAGE_PATH marc@localhost /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1 list /nix/store/q74q9piy9fsk4k7w1p3r3xc8wsm1z87m-ghc-6.6.1/lib/ghc-6.6.1/package.conf: Cabal-1.1.6.2, HUnit-1.1.1, QuickCheck-1.0.1, base-2.1.1, [...] /nix/store/fbj85ijnbc69bh19zi1a14p9idknb5g9-wxHaskell-0.10.1-pre20070124/nix-support/package.conf: wx-0.10.1, wxcore-0.10.1 Marc From phonohawk at ps.sakura.ne.jp Sun Jul 22 09:36:27 2007 From: phonohawk at ps.sakura.ne.jp (PHO) Date: Sun Jul 22 09:30:02 2007 Subject: ForeignPtr and -threaded Message-ID: <20070722.223627.55497502.phonohawk@ps.sakura.ne.jp> Hi, I have encountered a weird behavior of ForeignPtr. I want to know how to work around this. I am using GHC 6.6.1 on Darwin. [1] Foreign.Concurrent The following code prints "called" when it is linked with -threaded RTS, but it prints nothing when it isn't. import Foreign.Marshal.Alloc import qualified Foreign.Concurrent as Conc main = do mem <- mallocBytes 10 Conc.newForeignPtr mem $ print "called" [2] Foreign.ForeignPtr The following code prints nothing when it isn't linked with -threaded RTS, but when it is, it *sometimes* prints "called" but not always. import Foreign.Marshal.Alloc import Foreign.Ptr import Foreign.ForeignPtr foreign import ccall "wrapper" mkFinalizer :: (Ptr () -> IO ()) -> IO (FunPtr (Ptr () -> IO ())) main = do mem <- mallocBytes 10 fin <- mkFinalizer $ \ _ -> print "called" newForeignPtr fin mem _______________________________________________________ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070722/86f8c434/attachment.bin From bulat.ziganshin at gmail.com Sun Jul 22 09:48:05 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Jul 22 09:48:00 2007 Subject: ForeignPtr and -threaded In-Reply-To: <20070722.223627.55497502.phonohawk@ps.sakura.ne.jp> References: <20070722.223627.55497502.phonohawk@ps.sakura.ne.jp> Message-ID: <47252247.20070722174805@gmail.com> Hello PHO, Sunday, July 22, 2007, 5:36:27 PM, you wrote: > [2] Foreign.ForeignPtr > The following code prints nothing when it isn't linked with -threaded > RTS, but when it is, it *sometimes* prints "called" but not always. > import Foreign.Marshal.Alloc > import Foreign.Ptr > import Foreign.ForeignPtr > foreign import ccall "wrapper" > mkFinalizer :: (Ptr () -> IO ()) -> IO (FunPtr (Ptr () -> IO ())) > main = do mem <- mallocBytes 10 > fin <- mkFinalizer $ \ _ -> print "called" > newForeignPtr fin mem try to add performGC at end - this should force collecting garbage and therefore printing of string. otherwise, it's ok - there is no guarantee that GC will be performed and therefore that you finalizer will be performed. it's rather stanard behavior for GC languages - finalizers are almosr useless there -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From duncan.coutts at worc.ox.ac.uk Sun Jul 22 18:48:45 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jul 22 18:41:06 2007 Subject: ghc-pkg: can't unregister - not found - describe works? In-Reply-To: <20070721142558.GJ23433@gmx.de> References: <20070721142558.GJ23433@gmx.de> Message-ID: <1185144526.26804.130.camel@localhost> On Sat, 2007-07-21 at 16:25 +0200, Marc Weber wrote: > marc@localhost /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1 unregister wx > ghc-pkg: cannot find package wx > marc@localhost /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1 describe wx > name: wx > version: 0.10.1 > license: AllRightsReserved > [...] > > What does happen here? > ghc-pkg-wrapper is just a simple script defining GHC_PACKAGE_PATH > > marc@localhost /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1 list > /nix/store/q74q9piy9fsk4k7w1p3r3xc8wsm1z87m-ghc-6.6.1/lib/ghc-6.6.1/package.conf: > Cabal-1.1.6.2, HUnit-1.1.1, QuickCheck-1.0.1, base-2.1.1, > [...] > /nix/store/fbj85ijnbc69bh19zi1a14p9idknb5g9-wxHaskell-0.10.1-pre20070124/nix-support/package.conf: > wx-0.10.1, wxcore-0.10.1 The wx package is in your 'user' package db rather than in the 'global' one. All ghc-pkg operations operate on the global one by default, use the --user flag to operate on the user db: $ ghc-pkg --user unregister wx $ ghc-pkg --user unregister wxcore Duncan From phonohawk at ps.sakura.ne.jp Sun Jul 22 22:07:40 2007 From: phonohawk at ps.sakura.ne.jp (PHO) Date: Sun Jul 22 22:00:43 2007 Subject: ForeignPtr and -threaded In-Reply-To: <47252247.20070722174805@gmail.com> References: <20070722.223627.55497502.phonohawk@ps.sakura.ne.jp> <47252247.20070722174805@gmail.com> Message-ID: <20070723.110740.74755333.phonohawk@ps.sakura.ne.jp> From: Bulat Ziganshin Subject: Re: ForeignPtr and -threaded Date: Sun, 22 Jul 2007 17:48:05 +0400 > try to add performGC at end - this should force collecting garbage and > therefore printing of string. otherwise, it's ok - there is no guarantee > that GC will be performed and therefore that you finalizer will be > performed. it's rather stanard behavior for GC languages - finalizers > are almosr useless there So I changed the code like this but the result was exactly the same. The documentations of both Foreign.ForeignPtr (*1) and Foreign.Concurrent (*2) say "The only guarantee is that the finalizer runs before the program terminates." So I expected the finalizer to be called. import Foreign.Marshal.Alloc import Foreign.Ptr import Foreign.ForeignPtr import System.Mem import qualified Foreign.Concurrent as Conc main = work >> performGC where work = do mem <- mallocBytes 10 Conc.newForeignPtr mem $ print "called" *1: http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignPtr.html *2: http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Concurrent.html _______________________________________________________ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070723/cd60720f/attachment.bin From igloo at earth.li Mon Jul 23 04:22:01 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Jul 23 04:14:54 2007 Subject: ForeignPtr and -threaded In-Reply-To: <20070723.110740.74755333.phonohawk@ps.sakura.ne.jp> References: <20070722.223627.55497502.phonohawk@ps.sakura.ne.jp> <47252247.20070722174805@gmail.com> <20070723.110740.74755333.phonohawk@ps.sakura.ne.jp> Message-ID: <20070723082201.GA26520@matrix.chaos.earth.li> On Mon, Jul 23, 2007 at 11:07:40AM +0900, PHO wrote: > > same. The documentations of both Foreign.ForeignPtr (*1) and > Foreign.Concurrent (*2) say "The only guarantee is that the finalizer > runs before the program terminates." That's a documentation bug. In the HEAD it says: newForeignPtr :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a) -- ^Turns a plain memory reference into a foreign pointer, and -- associates a finaliser with the reference. The finaliser will be executed -- after the last reference to the foreign object is dropped. Note that there -- is no guarantee on how soon the finaliser is executed after the last -- reference was dropped; this depends on the details of the Haskell storage -- manager. Indeed, there is no guarantee that the finalizer is executed at -- all; a program may exit with finalizers outstanding. (This is true -- of GHC, other implementations may give stronger guarantees). Thanks Ian From phonohawk at ps.sakura.ne.jp Mon Jul 23 06:07:46 2007 From: phonohawk at ps.sakura.ne.jp (PHO) Date: Mon Jul 23 06:00:50 2007 Subject: ForeignPtr and -threaded In-Reply-To: <20070723082201.GA26520@matrix.chaos.earth.li> References: <47252247.20070722174805@gmail.com> <20070723.110740.74755333.phonohawk@ps.sakura.ne.jp> <20070723082201.GA26520@matrix.chaos.earth.li> Message-ID: <20070723.190746.189732438.phonohawk@ps.sakura.ne.jp> From: Ian Lynagh Subject: Re: ForeignPtr and -threaded Date: Mon, 23 Jul 2007 09:22:01 +0100 > That's a documentation bug. In the HEAD it says: > > newForeignPtr :: FinalizerPtr a -> Ptr a -> IO (ForeignPtr a) > -- ^Turns a plain memory reference into a foreign pointer, and > -- associates a finaliser with the reference. The finaliser will be executed > -- after the last reference to the foreign object is dropped. Note that there > -- is no guarantee on how soon the finaliser is executed after the last > -- reference was dropped; this depends on the details of the Haskell storage > -- manager. Indeed, there is no guarantee that the finalizer is executed at > -- all; a program may exit with finalizers outstanding. (This is true > -- of GHC, other implementations may give stronger guarantees). Uh, ok... Thank you for your information. _______________________________________________________ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070723/27e10b59/attachment.bin From garious at gmail.com Tue Jul 24 16:21:00 2007 From: garious at gmail.com (Greg Fitzgerald) Date: Tue Jul 24 16:13:45 2007 Subject: OPTIONS_GHC -iMyDir Message-ID: <1f3dc80d0707241321y523d9b9ayda8bb4e97af558cc@mail.gmail.com> I notice that some of GHC's command-line parameters do not work from within the OPTIONS_GHC pragma (6.6.1 on Windows). I can see how that makes sense for some parameters like "--make", but what about "-i" and "-v"? Is this intentional or a bug? Can't specify the include path: {-# OPTIONS_GHC -iMyDir #-} Can't compile a single file in 'verbose' mode: {-# OPTIONS_GHC -v #-} Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070724/f25ac82b/attachment.htm From stefanor at cox.net Tue Jul 24 17:01:07 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Jul 24 16:53:54 2007 Subject: OPTIONS_GHC -iMyDir In-Reply-To: <1f3dc80d0707241321y523d9b9ayda8bb4e97af558cc@mail.gmail.com> References: <1f3dc80d0707241321y523d9b9ayda8bb4e97af558cc@mail.gmail.com> Message-ID: <20070724210106.GA5331@localhost.localdomain> On Tue, Jul 24, 2007 at 01:21:00PM -0700, Greg Fitzgerald wrote: > I notice that some of GHC's command-line parameters do not work from within > the OPTIONS_GHC pragma (6.6.1 on Windows). I can see how that makes sense > for some parameters like "--make", but what about "-i" and "-v"? Is this > intentional or a bug? > > Can't specify the include path: > {-# OPTIONS_GHC -iMyDir #-} > > Can't compile a single file in 'verbose' mode: > {-# OPTIONS_GHC -v #-} > > Thanks, > Greg It's quite intentional, and documented. http://haskell.org/ghc/dist/current/docs/users_guide/static-dynamic-flags.html (that said, more parameters are static than really should be, esp in older versions of GHC) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070724/d931410d/attachment.bin From petersen at haskell.org Wed Jul 25 22:15:19 2007 From: petersen at haskell.org (Jens Petersen) Date: Wed Jul 25 22:08:01 2007 Subject: building ghc6 on ppc64 linux Message-ID: I am starting work on trying to bootstrap ghc-6.6.1 on ppc64 (yes 64bit) linux for Fedora. Has anyone successfully built it on ppc64 yet? The latest build I can find in a distro is ghc-6.4.2 in gentoo. Has anyone tried ghc6 on ppc64? Thanks in advance for idea comments or experiences you can share, Jens From naur at post11.tele.dk Fri Jul 27 04:17:13 2007 From: naur at post11.tele.dk (Thorkil Naur) Date: Fri Jul 27 04:14:53 2007 Subject: Is "-O currently also implies -fvia-C." still true? Message-ID: <200707271017.18444.naur@post11.tele.dk> Hello, The GHC User's Guide, Versio 6.6.1 (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html) says: -O currently also implies -fvia-C. I seem to remember some communication a while back that seemed to imply that this is no longer the case. So my question is: Is the quoted statement still true? Thanks and best regards Thorkil From Christian.Maeder at dfki.de Fri Jul 27 06:54:05 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jul 27 06:46:35 2007 Subject: Is "-O currently also implies -fvia-C." still true? In-Reply-To: <200707271017.18444.naur@post11.tele.dk> References: <200707271017.18444.naur@post11.tele.dk> Message-ID: <46A9CECD.7060907@dfki.de> Thorkil Naur wrote: > Hello, > > The GHC User's Guide, Versio 6.6.1 > (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html) > says: > > -O currently also implies -fvia-C. Yes, and -O0 implies -fasm (if -fasm or -fvia-C are not explicitly given). I noticed that when compiling ghc-6.6.1 for Mac OS with various flags. C. From isaacdupree at charter.net Fri Jul 27 14:16:19 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Jul 27 14:15:03 2007 Subject: Is "-O currently also implies -fvia-C." still true? In-Reply-To: <200707271017.18444.naur@post11.tele.dk> References: <200707271017.18444.naur@post11.tele.dk> Message-ID: <46AA3673.9010409@charter.net> Thorkil Naur wrote: > Hello, > > The GHC User's Guide, Versio 6.6.1 > (http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html) > says: > > -O currently also implies -fvia-C. > > I seem to remember some communication a while back that seemed to imply that > this is no longer the case. So my question is: Is the quoted statement still > true? True in 6.6.x, false in 6.7 (HEAD), in my experience. Isaac From mai99dgf at studserv.uni-leipzig.de Sat Jul 28 14:50:36 2007 From: mai99dgf at studserv.uni-leipzig.de (Georg Martius) Date: Sat Jul 28 14:37:41 2007 Subject: *****SPAM***** Annotation for unfolding wanted Message-ID: <200707282050.37246.mai99dgf@studserv.uni-leipzig.de> Spam detection software, running on the system "h7568.serverkompetenz.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, I was wondering why we don't have an annotation or pragma for function to tell the compiler that we need this particular recursive function to be unfolded. If the compiler cannot do this for some reason it should produce an error message to help you modifying your code. I have regularly problems that my code is either not strict enough or my functions are not unfolded. I find it annoying that this is a regular show stopper and consumes much time to fix. Here is an example: a search function for strings, which should return the index and the rest of the string after the first occurrence: search0 will not be unfolded by ghc -O. (I don't know why, it looks tail-recursive to me) whereas search1 is just fine. [...] Content analysis details: (7.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 FORGED_RCVD_HELO Received: contains a forged HELO 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.0000] 1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [87.172.170.59 listed in combined.njabl.org] 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [87.172.170.59 listed in dnsbl.sorbs.net] The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: Georg Martius Subject: Annotation for unfolding wanted Date: Sat, 28 Jul 2007 20:50:36 +0200 Size: 2583 Url: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070728/afd4c0cc/attachment.eml From igloo at earth.li Sat Jul 28 16:08:37 2007 From: igloo at earth.li (Ian Lynagh) Date: Sat Jul 28 16:01:11 2007 Subject: using Haskell readline package on Cygwin In-Reply-To: <97f280ea0707080512q270fa208v1ac2014d5cac396f@mail.gmail.com> References: <97f280ea0707080512q270fa208v1ac2014d5cac396f@mail.gmail.com> Message-ID: <20070728200837.GA9679@matrix.chaos.earth.li> Hi Amir, On Sun, Jul 08, 2007 at 03:12:27PM +0300, Amir E. Aharoni wrote: > > Is it possible to install the readline package manually? I haven't tried, but I suspect that doing a darcs get --partial http://darcs.haskell.org/packages/readline/ and then * removing the build-depend on process in readline.cabal * running autoreconf * building with Cabal as described in http://www.haskell.org/haskellwiki/How_to_install_a_Cabal_package will work. Thanks Ian From catamorphism at gmail.com Sat Jul 28 19:39:06 2007 From: catamorphism at gmail.com (Tim Chevalier) Date: Sat Jul 28 19:31:37 2007 Subject: *****SPAM***** Annotation for unfolding wanted In-Reply-To: <200707282050.37246.mai99dgf@studserv.uni-leipzig.de> References: <200707282050.37246.mai99dgf@studserv.uni-leipzig.de> Message-ID: <4683d9370707281639k65c1b58es68b266d097c2194@mail.gmail.com> Have you tried using the INLINE pragma? http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#inline-noinline-pragma Cheers, Tim -- Tim Chevalier* catamorphism.org *Often in error, never in doubt "You have not proven yourselves smart enough to act that stupid all the time and get away with it." -- Andrea Nemerson From mai99dgf at studserv.uni-leipzig.de Sun Jul 29 06:21:27 2007 From: mai99dgf at studserv.uni-leipzig.de (Georg Martius) Date: Sun Jul 29 06:08:30 2007 Subject: *****SPAM***** Annotation for unfolding wanted Message-ID: <200707291221.27798.mai99dgf@studserv.uni-leipzig.de> Spam detection software, running on the system "h7568.serverkompetenz.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Tim, thanks for the hint, but I tried this without success. My point is, that I don't want to try a pragma and see whether it works. I would like to specify the requirement that a function has to be in constant space and if it cannot be done, that the program should not compile. Would it be complicated to include in the compiler? [...] Content analysis details: (7.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 FORGED_RCVD_HELO Received: contains a forged HELO 3.0 BAYES_95 BODY: Bayesian spam probability is 95 to 99% [score: 0.9674] 1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [87.172.161.188 listed in combined.njabl.org] 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [87.172.161.188 listed in dnsbl.sorbs.net] 0.2 AWL AWL: From: address is in the auto white-list -------------- next part -------------- An embedded message was scrubbed... From: Georg Martius Subject: Annotation for unfolding wanted Date: Sun, 29 Jul 2007 12:21:27 +0200 Size: 1220 Url: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070729/feae788c/attachment.eml From seth at cql.com Sun Jul 29 11:33:40 2007 From: seth at cql.com (Seth Kurtzberg) Date: Sun Jul 29 11:26:17 2007 Subject: *****SPAM***** Annotation for unfolding wanted In-Reply-To: <200707291221.27798.mai99dgf@studserv.uni-leipzig.de> References: <200707291221.27798.mai99dgf@studserv.uni-leipzig.de> Message-ID: <000901c7d1f5$d6d42ad0$847c8070$@com> Anybody know what spam detection program is producing this absurd result, so I can make sure I never even think about using it? It's the second such email in two (or possibly three) days. The potential of Bayesian filtering is vastly overstated, but this one has to be a bug or usage error of some sort. -----Original Message----- From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Georg Martius Sent: Sunday, July 29, 2007 6:21 AM To: glasgow-haskell-users@haskell.org Subject: *****SPAM***** Annotation for unfolding wanted Spam detection software, running on the system "h7568.serverkompetenz.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Tim, thanks for the hint, but I tried this without success. My point is, that I don't want to try a pragma and see whether it works. I would like to specify the requirement that a function has to be in constant space and if it cannot be done, that the program should not compile. Would it be complicated to include in the compiler? [...] Content analysis details: (7.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.1 FORGED_RCVD_HELO Received: contains a forged HELO 3.0 BAYES_95 BODY: Bayesian spam probability is 95 to 99% [score: 0.9674] 1.9 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [87.172.161.188 listed in combined.njabl.org] 2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [87.172.161.188 listed in dnsbl.sorbs.net] 0.2 AWL AWL: From: address is in the auto white-list From petersen at haskell.org Sun Jul 29 22:02:45 2007 From: petersen at haskell.org (Jens Petersen) Date: Sun Jul 29 21:55:13 2007 Subject: building ghc6 on ppc64 linux In-Reply-To: References: Message-ID: On 7/26/07, Jens Petersen wrote: > I am starting work on trying to bootstrap ghc-6.6.1 on ppc64 (yes 64bit) linux > for Fedora. > > Has anyone successfully built it on ppc64 yet? The latest build I can > find in a distro is ghc-6.4.2 in gentoo. Has anyone tried ghc [6.6.1] on ppc64? Ok I tried and building the fedora ghc-6.6.1 package on ppc64 with gentoo's ghc-6.4.2 ppc64 binary I got the following error: : /usr/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall -fno-warn-name-shadowing -fno-wa rn-unused-matches -DUSING_COMPAT -i../../compat -ignore-package Cabal -Rghc-tim ing -L../../compat -lghccompat Main.o Version.o Main.o:(.text+0x0): undefined reference to `__DISCARD__' Main.o:(.text+0x28): undefined reference to `__DISCARD__' Main.o:(.text+0x50): undefined reference to `__DISCARD__' Main.o:(.text+0x168): undefined reference to `__DISCARD__' Main.o:(.text+0x194): undefined reference to `__DISCARD__' Main.o:(.text+0x1c0): more undefined references to `__DISCARD__' follow collect2: ld returned 1 exit status Where should __DISCARD__ be defined? Jens From kahl at cas.mcmaster.ca Sun Jul 29 22:20:45 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Sun Jul 29 22:14:55 2007 Subject: building ghc6 on ppc64 linux In-Reply-To: (petersen@haskell.org) References: Message-ID: <20070730022045.27379.qmail@schroeder.cas.mcmaster.ca> > > > Has anyone successfully built it on ppc64 yet? The latest build I can > > find in a distro is ghc-6.4.2 in gentoo. Has anyone tried ghc [6.6.1] on ppc64? > I have a gentoo binary package built some time ago from the gentoo ebuild for 6.6.1: http://sqrl.mcmaster.ca/~kahl/Haskell/ghc-bin-6.6.1.tbz2 This is for 32-bit userland running on a 64-bit kernel --- the default in gentoo, and currently restricts to unregisterised build. Wolfram From heron_carvalho at bol.com.br Sun Jul 29 23:19:07 2007 From: heron_carvalho at bol.com.br (heron_carvalho) Date: Sun Jul 29 23:11:38 2007 Subject: Call for Submissions - First Workshop on Languages and Tools for Parallel and Distributed Programming (LTPD 2007) Message-ID: ------------------------------------------------------------ First Workshop on Languages and Tools for Parallel and Distributed Programming (LTPD 2007) http://computacao.ucpel.tche.br/ltpd/ Gramado, RS - Brazil Co-located with SBAC-PAD 2007 (24-27 October 2007) *** Submiss?o de artigos: 24 de Agosto *** ------------------------------------------------------------ The objective of this workshop is to bring together researchers working on the design and implementation of programming languages, tools and techniques for distributed, parallel and mobile programming. Submitted papers should present original research that is unpublished and not submitted elsewhere. We encourage the submission of work in progress, especially by MSc and PhD students. We plan to provide a friendly environment where researchers can discuss current and future trends in programming languages for parallel and distributed programming. Papers can be written in English, Portuguese and Spanish. Papers should have 4 pages, following the IEEE Computer Society Proceedings Manuscript Formatting Guidelines. All accepted papers will be published in the On-Line conference proceedings, and as a technical report. The SBAC-PAD organization will also publish the electronic proceedings in CD. We plan to publish selected high quality papers from the proceedings in a local brazilian journal. At least one author of an accepted paper must attend the workshop and all workshop attendees must be registered to SBAC-PAD. Topics of Interest ------ -- -------- Topics of interest include, but are not limited to: * Programming Multi-Core Machines * Coordination Languages * Concurrent and Parallel Garbage Collection * Type systems and semantics for parallel, distributed and mobile languages * Declarative parallel, distributed and mobile languages * Languages for mobile and ubiquitous computing * Calculi for Mobility and Concurrency * Design Patterns * Distributed Objects * Distributed Component Models * Mobile Agents Languages * Software issues for multicore or multithreaded processors Important Dates --------- ----- * Deadline for paper submission: August 24, 2007 * Accepted Papers Notification: September 10, 2007 * Camera-Ready Submission: September 17, 2007 Organizing Committee ---------- --------- Andr? Rauber Du Bois (Chair) - UCPel Francisco Heron de Carvalho Junior (Chair)- UFC Program Committe ------- -------- Adenauer Correa Yammin - UCPel Alcides Calsavara - PUCPR ?lvaro Freitas Moreira - UFRGS Andr? Rauber Du Bois - UCPel Andr? Santos - UFPE Claudio Fernando Resin Geyer - UFRGS Cristiano Vasconcellos - UFPel Francisco Heron De Carvalho Jr - UFC Hans-Wolfgang Loidl - LMU, Germany Iara Augustin - UFSM Jorge Luis Victoria Barbosa - Unisinos Marco T?lio de Oliveira Valente - PUC-MG Phil Trinder - Heriot-Watt University, UK Rafael Dueire Lins - UFPE Ricardo Corr?a - UFC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070730/f1e0683f/attachment.htm From petersen at haskell.org Mon Jul 30 00:36:17 2007 From: petersen at haskell.org (Jens Petersen) Date: Mon Jul 30 00:28:46 2007 Subject: building ghc6 on ppc64 linux In-Reply-To: <20070730040156.27552.qmail@schroeder.cas.mcmaster.ca> References: <20070730022045.27379.qmail@schroeder.cas.mcmaster.ca> <20070730040156.27552.qmail@schroeder.cas.mcmaster.ca> Message-ID: [Oops, I forgot to include g-h-u in my first reply.] On 30 Jul 2007 04:01:56 -0000, kahl@cas.mcmaster.ca wrote: > Perhaps the following snippet from the gentoo ebuild helps: > > # GHC build system knows to build unregisterised on alpha and hppa, > # but we have to tell it to build unregisterised on some other arches > if use ppc64 || use sparc; then > echo "GhcUnregisterised=YES" >> mk/build.mk > echo "GhcWithNativeCodeGen=NO" >> mk/build.mk > echo "GhcWithInterpreter=NO" >> mk/build.mk > echo "SplitObjs=NO" >> mk/build.mk > echo "GhcRTSWays := debug" >> mk/build.mk > echo "GhcNotThreaded=YES" >> mk/build.mk > fi Thanks for that tip - I shuold have thought to check. Unfortunately I still get the same undefined __DISCARD__ with that. Also perhaps I should mention that earlier I am seeing a *lot* of warnings like these: /usr/bin/ghc -H16m -O -I. -Iinclude -Rghc-timing -ignore-package Cabal -I../libraries -fglasgow-exts -no-recomp -c Compat/Directory.hs -o Compat/Directory.o -ohi Compat/Director y.hi Warning: retaining unknown function `.L.__stginit_CompatziDirectory' in output from C compiler Warning: retaining unknown function `.L.__stginit_CompatziDirectory_' in output from C compiler Warning: retaining unknown function `.L.CompatziDirectory_createDirectoryIfMissing_entry' in output from C compiler Warning: retaining unknown function `.L.s2U5_ret' in output from C compiler Warning: retaining unknown function `.L.s2PU_1_alt' in output from C compiler Warning: retaining unknown function `.L.s2PU_0_alt' in output from C compiler Warning: retaining unknown function `.L.s2U8_1_alt' in output from C compiler Warning: retaining unknown function `.L.s2U8_0_alt' in output from C compiler Warning: retaining unknown function `.L.s2U9_1_alt' in output from C compiler Warning: retaining unknown function `.L.s2U9_0_alt' in output from C compiler Warning: retaining unknown function `.L.s2Ua_1_alt' in output from C compiler Warning: retaining unknown function `.L.s2Ua_0_alt' in output from C compiler Warning: retaining unknown function `.L.s2Q0_dflt' in output from C compiler Warning: retaining unknown function `.L.s2PH_entry' in output from C compiler Warning: retaining unknown function `.L.r2Ly_entry' in output from C compiler Warning: retaining unknown function `.L.s2U2_1_alt' in output from C compiler Warning: retaining unknown function `.L.s2U2_0_alt' in output from C compiler Warning: retaining unknown function `.L.s2U3_ret' in output from C compiler : : : But I don't know if they matter or are related to my __DISCARD__ problem. Jens From georg.martius at web.de Mon Jul 30 10:09:21 2007 From: georg.martius at web.de (Georg Martius) Date: Mon Jul 30 10:01:53 2007 Subject: Annotation for unfolding wanted Message-ID: <200707301609.26276.georg.martius@web.de> Hi folks, sorry for multiple copies of this email, but my mailserver had a problem and thought I am sending spam which is hopefully not true. Since I got a replay allready I modified my mail a bit. I was wondering why we don't have an annotation or pragma for function to tell the compiler that we _need_ this particular recursive function to be unfolded. If the compiler cannot do this for some reason it should produce an error message to help you modifying your code. I have regularly problems that my code is either not strict enough or my functions are not unfolded. I find it annoying that this is a regular show stopper and consumes much time to fix. Here is an example: a search function for strings, which should return the index and the rest of the string after the first occurrence: search0 will not be unfolded by ghc -O even with {#- INLINE search0 -#} (I don't know why, it looks tail-recursive to me) whereas search1 is just fine. search0 :: Int -> String -> String -> (String, Int) search0 i [] _ = ([],i) search0 i haystack needle = let len = length needle in if isPrefixOf needle haystack then (drop len haystack, i+len) else search0 (seq i (i+1)) (drop 1 haystack) needle search1 :: Int -> String -> String -> (String, Int) search1 i [] _ = ([],i) search1 i haystack needle = let i = elemIndex True $ map (isPrefixOf needle) $ tails haystack len = length needle in case i of Just index -> (drop (index+len) haystack, index + len) Nothing -> ([],0) Regards! Georg -- ---- Georg Martius, Tel: +49 177 6413311 ----- ------- http://www.flexman.homeip.net ---------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070730/63737faa/attachment-0001.bin From simonpj at microsoft.com Tue Jul 31 05:22:14 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 31 05:14:39 2007 Subject: Annotation for unfolding wanted In-Reply-To: <200707301609.26276.georg.martius@web.de> References: <200707301609.26276.georg.martius@web.de> Message-ID: | I was wondering why we don't have an annotation or pragma for function to tell | the compiler that we _need_ this particular recursive function to be unfolded. | If the compiler cannot do this for some reason it should produce an error | message to help you modifying your code. I have regularly problems that my | code is either not strict enough or my functions are not unfolded. I find it | annoying that this is a regular show stopper and consumes much time to fix. | Here is an example: a search function for strings, which should return the | index and the rest of the string after the first occurrence: search0 will not | be unfolded by ghc -O even with {#- INLINE search0 -#} (I don't know why, it | looks tail-recursive to me) GHC never inlines recursive functions. Why not? Because doing so exposes a new inline opportunity. How many times would you like it inlined? Not forever, I assume! Some compilers unroll recursive functions by inlining them N times, for some fixed N (say 3 or so). This reduces the loop overheads. GHC doesn't do this, although it'd be nice, because it makes repeated traversals of the code, and it's hard to spot when the function has been unrolled 3 times and then stop. If you look at the code after unrolling 3 times, from scratch, there's another call just waiting to be inlined. I'm not saying this couldn't be improved -- but I don't see an easy way to improve it. Simon From bulat.ziganshin at gmail.com Tue Jul 31 06:18:36 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Jul 31 06:28:30 2007 Subject: Annotation for unfolding wanted In-Reply-To: References: <200707301609.26276.georg.martius@web.de> Message-ID: <1594795309.20070731141836@gmail.com> Hello Simon, Tuesday, July 31, 2007, 1:22:14 PM, you wrote: > GHC never inlines recursive functions. Why not? Because doing so > exposes a new inline opportunity. How many times would you like it inlined? Not forever, I assume! really, state of things in this area is not pleasant. making polymorphic function recursive kills the performance because it's no more inlined nor specialized - it may be called only with real dictionary. because i'm wrote polymorphic i/o library, i had many situations when in rare cases functions should call itself recursively like this: getChar = if bufferEmpty then fillBuffer; getChar else return *p++ (sorry for some pseudocode) and it was very inefficient. at the last end, i was need to create special functions to handle recursive calls and call it when buffer empty so that main function becomes non-recursive: getChar = if bufferEmpty then getChar' else return *p++ getChar' = fillBuffer; getChar it will be great if specifying INLINE for recursive function will mean that it should be inlined at least once and then call to non-polymorphic specialized version should be made. at least it will be ideal for code like this -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From cperfumo at gmail.com Tue Jul 31 09:32:02 2007 From: cperfumo at gmail.com (Cristian Perfumo) Date: Tue Jul 31 09:24:26 2007 Subject: Ticky Ticky profiling Message-ID: Hi all!. I modified build.mk in order to allow Ticky-Ticky profiling (GhcLibWays=t). Now, when I try to make I get this error: ------------------------------------------------------------------------ == make way=t all; PWD = (the_whole_path)/ghc-6.6.1/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -H32m -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -hisuf t_hi -hcsuf t_hc -osuf t_o -ticky -#include posix/Itimer.h -c PrimOps.cmm -o PrimOps.t_o ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): ToDo: tickyAllocThunk Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Any clue? Thanks in advance. Cristian Perfumo. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070731/25418b52/attachment.htm From georg.martius at web.de Tue Jul 31 09:52:53 2007 From: georg.martius at web.de (Georg Martius) Date: Tue Jul 31 09:45:18 2007 Subject: Annotation for unfolding wanted In-Reply-To: References: <200707301609.26276.georg.martius@web.de> Message-ID: <200707311552.57054.georg.martius@web.de> Hi Simon, thanks for the answer! I see why inlining is not a good idea, but why is it not unfolded. I mean we don't need any true recursion if the function is tail-recursive or am I mistaken? However my point was more on a semantic point of view: If I write a function in a recursive way, but actually do nothing else than a loop, I would like a) that the compiler unrolls it to a loop and b) that I can specify such a requirement, while violating it emits an error. I believe it would help to write the intended code straight away, especially for less advanced Haskell programmers, which don't know about the optimization details of the compiler. Cheers, Georg On Tuesday 31 July 2007 11:22, you wrote: > | I was wondering why we don't have an annotation or pragma for function to > | tell the compiler that we _need_ this particular recursive function to be > | unfolded. If the compiler cannot do this for some reason it should > | produce an error message to help you modifying your code. I have > | regularly problems that my code is either not strict enough or my > | functions are not unfolded. I find it annoying that this is a regular > | show stopper and consumes much time to fix. Here is an example: a search > | function for strings, which should return the index and the rest of the > | string after the first occurrence: search0 will not be unfolded by ghc -O > | even with {#- INLINE search0 -#} (I don't know why, it looks > | tail-recursive to me) > > GHC never inlines recursive functions. Why not? Because doing so exposes > a new inline opportunity. How many times would you like it inlined? Not > forever, I assume! > > Some compilers unroll recursive functions by inlining them N times, for > some fixed N (say 3 or so). This reduces the loop overheads. GHC doesn't > do this, although it'd be nice, because it makes repeated traversals of the > code, and it's hard to spot when the function has been unrolled 3 times and > then stop. If you look at the code after unrolling 3 times, from scratch, > there's another call just waiting to be inlined. > > I'm not saying this couldn't be improved -- but I don't see an easy way to > improve it. > > Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20070731/933e9276/attachment.bin From simonpj at microsoft.com Tue Jul 31 10:20:18 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Jul 31 10:12:42 2007 Subject: Annotation for unfolding wanted In-Reply-To: <200707311552.57054.georg.martius@web.de> References: <200707301609.26276.georg.martius@web.de> <200707311552.57054.georg.martius@web.de> Message-ID: | However my point was more on a semantic point of view: If I write a function | in a recursive way, but actually do nothing else than a loop, I would like | a) that the compiler unrolls it to a loop and | b) that I can specify such a requirement, while violating it emits an error. What does it mean to say "the compiler unrolls it to a loop". If GHC sees a tail recursive function, it certainly compiles it to a loop! (But that's not called "unrolling".) Simon From jmaessen at alum.mit.edu Tue Jul 31 10:36:53 2007 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Tue Jul 31 10:28:38 2007 Subject: Annotation for unfolding wanted In-Reply-To: References: <200707301609.26276.georg.martius@web.de> <200707311552.57054.georg.martius@web.de> Message-ID: <7E2A35BB-F772-4DDC-B0AA-C1F66BD80F58@alum.mit.edu> On Jul 31, 2007, at 10:20 AM, Simon Peyton-Jones wrote: > | However my point was more on a semantic point of view: If I write > a function > | in a recursive way, but actually do nothing else than a loop, I