GHC *is* resource hungry
Here is a harmless little program (no recursion, no data types) which GHC doesn't manage to compile (well, the kernel kills GHC after a while on a machine with generous 512MB of main memory and 1GB of swap space). begin next = next id leaf k i next = next (k i) fork k next = next (\ t u - k (t + u)) end x = x main = print (begin fork fork fork fork fork fork fork fork fork fork leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 end) Both Hugs and nhc98 accept it almost immediately. Cheers, Ralf ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC *is* resource hungry
I bet it's massive types. Translate the program into system F and see. (I remember this came up when looking at Okasaki's sequences of code combinators.) Your bet is most likely the correct one (yes, I peeked at Chris' HW2002 paper). GHC doesn't try to hash-cons types, because it usually doesn't matter, but I bet it does here. Would this be a major rewrite? [As an aside, a similiar problem showed up when generating conversion functions for generic representation types.] Cheers, Ralf | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Ralf Hinze | Sent: 28 May 2003 15:32 | To: [EMAIL PROTECTED] | Subject: GHC *is* resource hungry | | Here is a harmless little program (no recursion, no data types) | which GHC doesn't manage to compile (well, the kernel kills GHC | after a while on a machine with generous 512MB of main memory | and 1GB of swap space). | | begin next = next id | leaf k i next = next (k i) | fork k next = next (\ t u - k (t + u)) | end x = x | main = print (begin fork fork fork fork fork fork fork fork fork fork leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 | leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 end) | | Both Hugs and nhc98 accept it almost immediately. | | Cheers, Ralf | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC *is* resource hungry
| GHC doesn't try to hash-cons types, because it usually doesn't matter, | but I bet it does here. | | Would this be a major rewrite? [As an aside, a similiar problem showed up | when generating conversion functions for generic representation types.] I really don't know. Hash-consing is simple enough in principle, but Shao suggests using de-bruijn notation to avoid gratuitous differences between types. It's definitely not a routine matter. S | | Cheers, Ralf | | | -Original Message- | | From: [EMAIL PROTECTED] | | [mailto:[EMAIL PROTECTED] On | | | Behalf Of Ralf Hinze | | Sent: 28 May 2003 15:32 | | To: [EMAIL PROTECTED] | | Subject: GHC *is* resource hungry | | | | Here is a harmless little program (no recursion, no data types) | | which GHC doesn't manage to compile (well, the kernel kills GHC | | after a while on a machine with generous 512MB of main memory | | and 1GB of swap space). | | | | begin next = next id | | leaf k i next = next (k i) | | fork k next = next (\ t u - k (t + u)) | | end x = x | | main = print (begin fork fork fork fork fork fork fork fork fork | | fork leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 | | | leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 end) | | | | Both Hugs and nhc98 accept it almost immediately. | | | | Cheers, Ralf | | | | ___ | | Glasgow-haskell-bugs mailing list | | [EMAIL PROTECTED] | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs | ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC *is* resource hungry
As far as I know, Hugs doesn't hash-cons types, yet it manages to typecheck these pathalogical examples in reasonable time/space. I vaguely recall there being a specific modification to Hugs's typechecker to handle this, but I can't remember what it was. Cheers, Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Peyton-Jones Sent: 28 May 2003 15:57 To: Ralf Hinze Cc: GHC bugs Subject: RE: GHC *is* resource hungry I bet it's massive types. Translate the program into system F and see. (I remember this came up when looking at Okasaki's sequences of code combinators.) GHC doesn't try to hash-cons types, because it usually doesn't matter, but I bet it does here. S | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Ralf Hinze | Sent: 28 May 2003 15:32 | To: [EMAIL PROTECTED] | Subject: GHC *is* resource hungry | | Here is a harmless little program (no recursion, no data types) | which GHC doesn't manage to compile (well, the kernel kills GHC | after a while on a machine with generous 512MB of main memory | and 1GB of swap space). | | begin next = next id | leaf k i next = next (k i) | fork k next = next (\ t u - k (t + u)) | end x = x | main = print (begin fork fork fork fork fork fork fork fork fork fork leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 | leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 end) | | Both Hugs and nhc98 accept it almost immediately. | | Cheers, Ralf | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
n + k patterns
GHCi infers for fac 0 = 1 fac (n + 1) = (n + 1) * fac n the following type / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Compiling Main ( Fac.lhs, interpreted ) Ok, modules loaded: Main. *Main :t fac forall a. (Num a, Ord a) = a - a The Report, however, states that 3.17.2 Informal Semantics of Pattern Matching ... An n+k pattern can only be matched against a value in the class Integral. Cheers, Ralf ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC *is* resource hungry
I'm not sure it's the type inference so much as the type abstractions and applications. But yes, your point is a good one S | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On | Behalf Of Simon Marlow | Sent: 28 May 2003 18:03 | To: Simon Peyton-Jones; Ralf Hinze | Cc: GHC bugs | Subject: RE: GHC *is* resource hungry | | As far as I know, Hugs doesn't hash-cons types, yet it manages to | typecheck these pathalogical examples in reasonable time/space. I | vaguely recall there being a specific modification to Hugs's typechecker | to handle this, but I can't remember what it was. | | Cheers, | Simon | | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of | Simon Peyton-Jones | Sent: 28 May 2003 15:57 | To: Ralf Hinze | Cc: GHC bugs | Subject: RE: GHC *is* resource hungry | | I bet it's massive types. Translate the program into system | F and see. | (I remember this came up when looking at Okasaki's sequences of code | combinators.) | | GHC doesn't try to hash-cons types, because it usually doesn't matter, | but I bet it does here. | | S | | | -Original Message- | | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On | | Behalf Of Ralf Hinze | | Sent: 28 May 2003 15:32 | | To: [EMAIL PROTECTED] | | Subject: GHC *is* resource hungry | | | | Here is a harmless little program (no recursion, no data types) | | which GHC doesn't manage to compile (well, the kernel kills GHC | | after a while on a machine with generous 512MB of main memory | | and 1GB of swap space). | | | | begin next = next id | | leaf k i next = next (k i) | | fork k next = next (\ t u - k (t + u)) | | end x = x | | main = print (begin fork fork fork fork fork fork fork fork fork | fork leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 | | leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 leaf 0 end) | | | | Both Hugs and nhc98 accept it almost immediately. | | | | Cheers, Ralf | | | | ___ | | Glasgow-haskell-bugs mailing list | | [EMAIL PROTECTED] | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Removing greencard from project list
I'd like to remove greencard from the list of projects that can get built if you 'make' in fptools. I see a list AllProjects which include 'green-card' in fptools/mk/config.mk.in Is this the bit I need to edit? It looks plausible but I'm not certain. Yes, that should work. Why would you want to do that, though? Is it just the difficulty of maintaining two parallel Makefile setups? I found it useful to be able to build greencard in my source tree when I was testing your X11 library the other day. I did have to fiddle around quite a bit to make it work though. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: building ghc from source
On Thursday 29 May 2003 12:48 am, Mike Thomas wrote: 1. That Greencard and HDirect have been lagging behind the mainstream of GHC library changes for some time now - it has been hard to get them in step through the major FFI and library changes because few people have the time and/or knowledge to deal with the problems. Including them in distributions, make trees, etc doesn't seem to help that. They have been in the tree/ distrib for some time and that hasn't prevented them from lagging. My premise is that Win32 has been distributed as part of GHC for many years. Given that the Unix/Posix libs are too, I think that it would be nice to see Windows given the same courtesy. But there is a strong push to reduce the number of libraries shipped with GHC. Since there's no reason to include win32 in the distro, why not leave it out? We have to start somewhere. If it proves inconvenient to users to have to download 2 packages and install them in the right order, then we'll know we'll have a serious problem when we move to having a dozen packages. To that end I wanted to make it possible for Greencard to be more easily integrated into the nightly GHC build mechanism as, of course, Win32 depends on it. I'm fine with testing it, testing win32, etc. but don't want to have to wire it into the ghc build tree to do so. I see them as separate packages which just happen to use the fpconfig and glafp-utils packages too. Sorry if I seem to be rejecting your offer to help. At the moment I just want to get greencard, win32, x11 and hgl out the door. I'm tired of endlessly tweaking makefiles... -- Alastair Reid ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
