From mechvel at botik.ru Tue Oct 2 13:57:31 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Tue Oct 2 13:55:20 2007 Subject: bug in 6.8.1-candidate Message-ID: <20071002175731.GA31189@scico.botik.ru> Dear GHC developers, this is again on the `panic' bug in ghc-6.8.1-candidate. The archive http://botik.ru/pub/local/Mechveliani/ghcBugs/bug2-6.8.0-sep28.zip presents one more report on this bug. Unzip and see install.txt. The project is built, but the test program Test.hs cannot build, ghc reports of `panic'. Further, return to the project build: in the file GBasFld.hs, comment-out the type declaration for the function b_criterion_ev, and re-build the project. Now, it reports of `panic' when compiling GBasFld. Simply speaking, docon-2.11 works under ghc-6.6.1 and does not work under ghc-6.8.0-sep28.zip. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From waldmann at imn.htwk-leipzig.de Tue Oct 9 10:07:53 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Oct 9 10:06:37 2007 Subject: how to build API docs from snapshot? Message-ID: <470B8B39.4030806@imn.htwk-leipzig.de> How can I build the library API docs from a (source) snapshot, e.g. ghc-6.8.0.20070921-src-extralibs.tar.bz2 ? Thanks, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- From johan.tibell at gmail.com Tue Oct 9 10:58:25 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Oct 9 11:11:03 2007 Subject: how to build API docs from snapshot? In-Reply-To: <470B8B39.4030806@imn.htwk-leipzig.de> References: <470B8B39.4030806@imn.htwk-leipzig.de> Message-ID: <90889fe70710090758u5c69cb64m926f80fb1061ce7@mail.gmail.com> On 10/9/07, Johannes Waldmann wrote: > How can I build the library API docs from a (source) snapshot, > e.g. ghc-6.8.0.20070921-src-extralibs.tar.bz2 ? Thanks, http://hackage.haskell.org/trac/ghc/wiki/Building/Docs Normal make will build the documentation for you and "make install" will install it. -- Johan From waldmann at imn.htwk-leipzig.de Tue Oct 9 11:47:05 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Oct 9 11:45:39 2007 Subject: how to build API docs from snapshot? (solved) In-Reply-To: <90889fe70710090831v1e8f1542j4bd6c2d785be574b@mail.gmail.com> References: <470B8B39.4030806@imn.htwk-leipzig.de> <90889fe70710090758u5c69cb64m926f80fb1061ce7@mail.gmail.com> <470B9816.8060301@imn.htwk-leipzig.de> <90889fe70710090831v1e8f1542j4bd6c2d785be574b@mail.gmail.com> Message-ID: <470BA279.4000902@imn.htwk-leipzig.de> Johan Tibell wrote: > Did you change mk/build.mk before running ./configure and make? Ah! I did change this, but I forgot to (re-)configure. Thanks a lot. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- From ravi at bluespec.com Tue Oct 9 13:47:59 2007 From: ravi at bluespec.com (Ravi Nanavati) Date: Tue Oct 9 13:46:33 2007 Subject: Determining GHC version use to compile an executable? Message-ID: <7b977d860710091047l7806ef70t4cf9b83b69eaa3db@mail.gmail.com> I was wondering if there was a clever way to determine the GHC version that was used to compile a particular executable. I looked in the RTS flags and didn't see anything obvious, but I was wondering if I missed something or if there was a clever back door. It's not a big deal if there isn't but, if there is, it might help me diagnose a problem. Thanks, - Ravi From jpeliz at icmc.usp.br Tue Oct 9 14:29:55 2007 From: jpeliz at icmc.usp.br (Jorge Marques Pelizzoni) Date: Tue Oct 9 14:28:31 2007 Subject: is -fno-monomorphism-restriction evil? Message-ID: <10655.200.158.222.123.1191954595.squirrel@mail2.icmc.usp.br> Hi, all! It may be a side-effect of being a newbie, but many times I find the -fno-monomorphism-restriction quite handy. Is it intrinsically evil? I mean, has anyone had a bad time using it or does it imply some runtime performance overhead? I guess it is not portable, is it? Thanks in advance. Cheers, Jorge. From dons at galois.com Tue Oct 9 14:50:44 2007 From: dons at galois.com (Don Stewart) Date: Tue Oct 9 14:49:23 2007 Subject: Determining GHC version use to compile an executable? In-Reply-To: <7b977d860710091047l7806ef70t4cf9b83b69eaa3db@mail.gmail.com> References: <7b977d860710091047l7806ef70t4cf9b83b69eaa3db@mail.gmail.com> Message-ID: <20071009185044.GD7487@scytale.galois.com> ravi: > I was wondering if there was a clever way to determine the GHC version > that was used to compile a particular executable. I looked in the RTS > flags and didn't see anything obvious, but I was wondering if I missed > something or if there was a clever back door. It's not a big deal if > there isn't but, if there is, it might help me diagnose a problem. > Someting like: $ strings myHaskell.exe | sed -n '/^[0-9]\.[0-9]\.[0-9]/p' 6.9.20070916 Might work. E.g.: $ strings `which xmonad` | sed -n '/^[0-9]\.[0-9]\.[0-9]/p' 6.9.20070916 $ strings `which hmp3` | sed -n '/^[0-9]\.[0-9]\.[0-9]/p' 6.6.1 Cheers, Don From mdanish at andrew.cmu.edu Tue Oct 9 16:58:11 2007 From: mdanish at andrew.cmu.edu (Matthew Danish) Date: Tue Oct 9 16:56:54 2007 Subject: is -fno-monomorphism-restriction evil? In-Reply-To: <10655.200.158.222.123.1191954595.squirrel@mail2.icmc.usp.br> References: <10655.200.158.222.123.1191954595.squirrel@mail2.icmc.usp.br> Message-ID: <20071009205811.GI29000@mapcar.org> On Tue, Oct 09, 2007 at 03:29:55PM -0300, Jorge Marques Pelizzoni wrote: > It may be a side-effect of being a newbie, but many times I find the > -fno-monomorphism-restriction quite handy. Is it intrinsically evil? I > mean, has anyone had a bad time using it or does it imply some runtime > performance overhead? I guess it is not portable, is it? The worst that can happen is unexpected repeated computation. This arises because type-class constraints on polymorphism act like a "hidden parameter" to a function. In bindings of the form: var = ... you may have expected that the value of var is only computed once. However, if the type of var is polymorphic with type-class constraints, then it is "really" a function. var dictionary = ... where the dictionary is a parameter which supplies the method definitions for whichever type is being used. Simple example, a function which reverses the parameters of the method "compare" of the "Ord" type-class: f = flip compare This turns into f ordDict = flip (compare ordDict) and now instead of being a simple variable binding it could be recomputed each time it is used. There are 3 ways to address this issue: 1) explicit parameters: the restriction only applies to bindings of the form "var = ...", so if it's really a function, make those parameters explicit. f x y = compare y x 2) explicit type annotation: the restriction is lifted if you give an explicit type annotation. f :: Ord a => a -> a -> Ordering f = flip compare 3) -fno-monomorphism-restriction and equivalents Is -fno-monomorphism-restriction "evil"? No, I don't think so. I think there is some debate on whether the whole restriction should be lifted for Haskell' even. As for portability, you can now use: {-# LANGUAGE NoMonomorphismRestriction #-} at the top of your file. This should be more "portable" than a ghc-specific compiler option. See the GHC manual section on pragmas for the full details. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org From simonmarhaskell at gmail.com Wed Oct 10 04:01:23 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Oct 10 03:59:58 2007 Subject: Determining GHC version use to compile an executable? In-Reply-To: <20071009185044.GD7487@scytale.galois.com> References: <7b977d860710091047l7806ef70t4cf9b83b69eaa3db@mail.gmail.com> <20071009185044.GD7487@scytale.galois.com> Message-ID: <470C86D3.7070102@gmail.com> Don Stewart wrote: > ravi: >> I was wondering if there was a clever way to determine the GHC version >> that was used to compile a particular executable. I looked in the RTS >> flags and didn't see anything obvious, but I was wondering if I missed >> something or if there was a clever back door. It's not a big deal if >> there isn't but, if there is, it might help me diagnose a problem. >> > > Someting like: > > $ strings myHaskell.exe | sed -n '/^[0-9]\.[0-9]\.[0-9]/p' > 6.9.20070916 > > Might work. > > E.g.: > > $ strings `which xmonad` | sed -n '/^[0-9]\.[0-9]\.[0-9]/p' > 6.9.20070916 > > $ strings `which hmp3` | sed -n '/^[0-9]\.[0-9]\.[0-9]/p' > 6.6.1 With 6.8.1: > ./hello +RTS --info [("GHC RTS", "Yes") ,("GHC version", "6.8.0.20070919") ,("RTS way", "rts") ,("Host platform", "x86_64-unknown-linux") ,("Build platform", "x86_64-unknown-linux") ,("Target platform", "x86_64-unknown-linux") ,("Compiler unregisterised", "NO") ,("Tables next to code", "YES") ] Cheers, Simon From ketil+haskell at ii.uib.no Thu Oct 11 04:55:16 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Thu Oct 11 04:53:46 2007 Subject: GHC benchmarks Message-ID: <87zlyqjaiz.fsf@nmd9999.imr.no> Hi, I've recently implemented some benchmarks for my library, and while I expected a slowdown for 64-bit code, I'm a bit bit surprised by the results. In summary: with 64 bit ghc 6.6.1, my benchmark runs in ~160 seconds with 32 bit ghc 6.6, it runs in ~ 95 seconds Most of the time is traversing a list of elements, doing a few numerical calculations. Presumably this is due to increased code size due to 8-byte pointers? I'll add some more benchmarks, but just wondered whether this was to be expeced, and, if so, whether I perhaps should be running a 32 bit version of GHC? I tried to Google for other benchmark results, but couldn't find any. Are there any particular GHC options I should use for compiling 64-bit code? I'll install 6.8 RSN, perhaps that will improve things? Oh, and if anybody wants to play with it, it should be possible to install Data.Binary and HXT, and then: darcs get http://malde.org/~ketil/bio cd bio make bench -k -- If I haven't seen further, it is by standing in the footprints of giants From Christian.Maeder at dfki.de Thu Oct 11 09:28:17 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Oct 11 09:29:41 2007 Subject: GHC benchmarks In-Reply-To: <87zlyqjaiz.fsf@nmd9999.imr.no> References: <87zlyqjaiz.fsf@nmd9999.imr.no> Message-ID: <470E24F1.2050600@dfki.de> Ketil Malde wrote: > Hi, > > I've recently implemented some benchmarks for my library, and while I > expected a slowdown for 64-bit code, I'm a bit bit surprised by the > results. In summary: > > with 64 bit ghc 6.6.1, my benchmark runs in ~160 seconds > with 32 bit ghc 6.6, it runs in ~ 95 seconds here are my results (with reversed ghc versions) when running your code: with 64 bit ghc 6.6 254 secs with 32 bit ghc 6.6.1 146 secs Having noticed that the 64 bit ghc-6.6 is slower, I decided to install the 32 bit ghc-6.6.1 only. Cheers Christian my test machine: Dual Core AMD Opteron 2220Server 2800MHz 16GB RAM Linux pollux 2.6.16.27-0.6-xenlocal x86_64 GNU/Linux From simonmarhaskell at gmail.com Thu Oct 11 09:35:05 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Oct 11 09:33:39 2007 Subject: GHC benchmarks In-Reply-To: <87zlyqjaiz.fsf@nmd9999.imr.no> References: <87zlyqjaiz.fsf@nmd9999.imr.no> Message-ID: <470E2689.8040300@gmail.com> Ketil Malde wrote: > I've recently implemented some benchmarks for my library, and while I > expected a slowdown for 64-bit code, I'm a bit bit surprised by the > results. In summary: > > with 64 bit ghc 6.6.1, my benchmark runs in ~160 seconds > with 32 bit ghc 6.6, it runs in ~ 95 seconds > > Most of the time is traversing a list of elements, doing a few > numerical calculations. Presumably this is due to increased code size > due to 8-byte pointers? Not so much code size, but data size (heap size, to be more precise). The amount of data shuffled around at runtime is doubled when running a 64-bit version of GHC - the GC has to do twice as much work. The cache hit rate drops, for a given cache size. It would be interesting to know how much time is spent in the GC - run the program with +RTS -sstderr. > I'll add some more benchmarks, but just wondered whether this was to > be expeced, and, if so, whether I perhaps should be running a 32 bit > version of GHC? I guess it's moderately surprising, I don't expect to see that much difference usually. But I suppose if the memory demands of your program are high, then it could be reasonable. There are benefits to running on 64 bits: more registers in particular, but this doesn't outweight the extra memory overhead for us usually. Cheers, Simon From ketil+haskell at ii.uib.no Fri Oct 12 04:58:52 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Oct 12 04:57:17 2007 Subject: GHC benchmarks In-Reply-To: <470E2689.8040300@gmail.com> (Simon Marlow's message of "Thu\, 11 Oct 2007 14\:35\:05 +0100") References: <87zlyqjaiz.fsf@nmd9999.imr.no> <470E2689.8040300@gmail.com> Message-ID: <87lka83e0j.fsf@nmd9999.imr.no> Simon Marlow writes: > Not so much code size, but data size (heap size, to be more > precise). Of course. There was some talk about storing tags in pointers for 6.8, I couldn't find the reference, but I wonder if that would help my situation? > It would be interesting to know how much time is spent in the GC - run > the program with +RTS -sstderr. MUT time decreases a bit (131 to 127s) for x86_64, but GC time increases a lot (98 to 179s). i686 version: ---------------------------------------- 94,088,199,152 bytes allocated in the heap 22,294,740,756 bytes copied during GC (scavenged) 2,264,823,784 bytes copied during GC (not scavenged) 124,747,644 bytes maximum residency (4138 sample(s)) 179962 collections in generation 0 ( 67.33s) 4138 collections in generation 1 ( 30.92s) 248 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 131.53s (133.03s elapsed) GC time 98.25s (100.13s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 229.78s (233.16s elapsed) %GC time 42.8% (42.9% elapsed) Alloc rate 715,345,865 bytes per MUT second Productivity 57.2% of total user, 56.4% of total elapsed ---------------------------------------- x86_64 version: ---------------------------------------- 173,790,326,352 bytes allocated in the heap 59,874,348,560 bytes copied during GC (scavenged) 5,424,298,832 bytes copied during GC (not scavenged) 247,477,744 bytes maximum residency (9856 sample(s)) 331264 collections in generation 0 (111.51s) 9856 collections in generation 1 ( 67.80s) 582 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 127.20s (127.76s elapsed) GC time 179.32s (179.63s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 306.52s (307.39s elapsed) %GC time 58.5% (58.4% elapsed) Alloc rate 1,366,233,874 bytes per MUT second Productivity 41.5% of total user, 41.4% of total elapsed ---------------------------------------- I've also added results from the 64 bit ghc-6.8.20071011 binary snapshot, which shows some nice improvements, with one benchmark improving by 30%(!). ---------------------------------------- 151,807,589,712 bytes allocated in the heap 50,687,462,360 bytes copied during GC (scavenged) 4,472,003,520 bytes copied during GC (not scavenged) 256,532,480 bytes maximum residency (6805 sample(s)) 289342 collections in generation 0 ( 89.30s) 6805 collections in generation 1 ( 60.26s) 602 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 83.79s ( 84.36s elapsed) GC time 149.57s (151.10s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 233.35s (235.47s elapsed) %GC time 64.1% (64.2% elapsed) Alloc rate 1,811,779,785 bytes per MUT second Productivity 35.9% of total user, 35.6% of total elapsed ---------------------------------------- >> I'll add some more benchmarks And I did. Below is a bit more detail from the log. The "rc hash counts" traverse a bytestring, hashing fixed-size words into Integers. As you can see, I haven't yet gotten the SPECIALIZE pragma to work correctly :-). The "global alignment" is the previous test, performing global (Needleman-Wunsch) alignment on pairs of sequences of length 100 (short) or 1000 (long), implementing the dynamic programming matrix as a list of lists. ==================== Start:Fri Oct 12 08:48:36 CEST 2007 Linux nmd9999 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686 GNU/Linux ghc 6.6 --- Sequence bench --- rc hash counts int (8) ..... OK, passed 10 tests, CPU time: 34.526157s rc hash counts int (16) ..... OK, passed 10 tests, CPU time: 34.746172s rc hash counts (16) ..... OK, passed 10 tests, CPU time: 34.642164s rc hash counts (32) ..... OK, passed 10 tests, CPU time: 35.378212s Sequence bench totals, CPU time: 139.292705s, wall clock: 139 secs --- Alignment bench --- global alignment, short ..... OK, passed 10 tests, CPU time: 2.696168s global alignment, long ...... OK, passed 10 tests, CPU time: 90.481655s Alignment bench totals, CPU time: 93.177823s, wall clock: 94 secs Total for all tests, CPU time: 232.474528s, wall clock: 233 secs End:Fri Oct 12 08:52:29 CEST 2007 ==================== Start:Fri Oct 12 09:52:33 CEST 2007 Linux nmd9999.imr.no 2.6.22-13-generic #1 SMP Thu Oct 4 17:52:26 GMT 2007 x86_64 GNU/Linux ghc 6.6.1 --- Sequence bench --- rc hash counts int (8) ..... OK, passed 10 tests, CPU time: 36.634289s rc hash counts int (16) ..... OK, passed 10 tests, CPU time: 36.590286s rc hash counts (16) ..... OK, passed 10 tests, CPU time: 36.946309s rc hash counts (32) ..... OK, passed 10 tests, CPU time: 37.402338s Sequence bench totals, CPU time: 147.577222s, wall clock: 148 secs --- Alignment bench --- global alignment, short ..... OK, passed 10 tests, CPU time: 3.564223s global alignment, long ...... OK, passed 10 tests, CPU time: 156.101756s Alignment bench totals, CPU time: 159.665979s, wall clock: 159 secs Total for all tests, CPU time: 307.247201s, wall clock: 307 secs End:Fri Oct 12 09:57:40 CEST 2007 ==================== Start:Fri Oct 12 10:51:27 CEST 2007 Linux nmd9999.imr.no 2.6.22-13-generic #1 SMP Thu Oct 4 17:52:26 GMT 2007 x86_64 GNU/Linux ghc 6.8.0.20071011 --- Sequence bench --- rc hash counts int (8) ..... OK, passed 10 tests, CPU time: 22.773423s rc hash counts int (16) ..... OK, passed 10 tests, CPU time: 22.657416s rc hash counts (16) ..... OK, passed 10 tests, CPU time: 22.513407s rc hash counts (32) ..... OK, passed 10 tests, CPU time: 23.009438s Sequence bench totals, CPU time: 90.953684s, wall clock: 91 secs --- Alignment bench --- global alignment, short ..... OK, passed 10 tests, CPU time: 3.168198s global alignment, long ...... OK, passed 10 tests, CPU time: 140.808799s Alignment bench totals, CPU time: 143.976997s, wall clock: 144 secs Total for all tests, CPU time: 234.930681s, wall clock: 235 secs End:Fri Oct 12 10:55:23 CEST 2007 -k -- If I haven't seen further, it is by standing in the footprints of giants From ketil+haskell at ii.uib.no Fri Oct 12 07:01:09 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Fri Oct 12 06:59:31 2007 Subject: GHC benchmarks In-Reply-To: <87lka83e0j.fsf@nmd9999.imr.no> (Ketil Malde's message of "Fri\, 12 Oct 2007 10\:58\:52 +0200") References: <87zlyqjaiz.fsf@nmd9999.imr.no> <470E2689.8040300@gmail.com> <87lka83e0j.fsf@nmd9999.imr.no> Message-ID: <87zlyo1tsa.fsf@nmd9999.imr.no> Ketil Malde writes: > I've also added results from the 64 bit ghc-6.8.20071011 binary > snapshot, which shows some nice improvements, with one benchmark > improving by 30%(!). One difference between these runs is that the ByteString library, on which this particular benchmark depends heavily, got upgraded from fps-0.7 to bytestring-0.9. I initially thought some of the performance increase could be due to that, but after some contortions, I find that 6.6.1 with bytestring-0.9 gives me slightly worse results(!) (I haven't yet entirely convinced myself that I got this properly set up, but at least ghci lets me :m Data.ByteString.Lazy.Internals, which I believe is a new addition) Here are the numbers: --- Sequence bench --- rc hash counts int (8) ..... OK, passed 10 tests, CPU time: 38.778423s rc hash counts int (16) ..... OK, passed 10 tests, CPU time: 38.522408s rc hash counts (16) ..... OK, passed 10 tests, CPU time: 38.694418s rc hash counts (32) ..... OK, passed 10 tests, CPU time: 39.170448s Sequence bench totals, CPU time: 155.165697s, wall clock: 155 secs --- Alignment bench --- global alignment, short ..... OK, passed 10 tests, CPU time: 3.492218s global alignment, long ...... OK, passed 10 tests, CPU time: 152.497531s Alignment bench totals, CPU time: 155.989749s, wall clock: 156 secs Total for all tests, CPU time: 311.155446s, wall clock: 311 secs -k -- If I haven't seen further, it is by standing in the footprints of giants From jpeliz at icmc.usp.br Sat Oct 13 03:59:35 2007 From: jpeliz at icmc.usp.br (Jorge Marques Pelizzoni) Date: Sat Oct 13 03:58:06 2007 Subject: undecidable & overlapping instances: a bug? Message-ID: <11288.200.158.223.162.1192262375.squirrel@mail2.icmc.usp.br> Hi, all! I am quite intrigued at the behaviour examplified in the attached module. It's true I am a newbie and probably don't quite get the whole consequence spectrum of -fallow-undecidable-instances, but why providing that dummy instance (commented out) get the thing to compile? By the way, I'm using GHC 6.6 on WinXP (actually, latest Visual Haskell with MS Visual Studio 2005) and the error message I get is: FooModule.hs:13:9: Could not deduce (Show a) from the context (Concrete a b) arising from use of `bar' at FooModule.hs:13:9-13 Possible fix: add (Show a) to the class or instance method `foo' In the expression: bar x In the definition of `foo': foo x = bar x In the definition for method `foo' A second question: which kinds of overlapping are covered by -fallow-overlapping-instances? It seems that the following (also in the attached module) is not allowed: instance (Show a, Abstract a b) => Concrete a b where foo x = show x instance (Abstract a b) => Concrete a b which gives me the message: FooModule.hs:17:0: Duplicate instance declarations: instance [overlap ok] (Show a, Abstract a b) => Concrete a b -- Defined at FooModule.hs:17:0 instance [overlap ok] (Abstract a b) => Concrete a b -- Defined at FooModule.hs:30:0 Thanks in advance for any pointers. Cheers, Jorge. -------------- next part -------------- A non-text attachment was scrubbed... Name: FooModule.hs Type: application/octet-stream Size: 685 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071013/adb9b5ab/FooModule.obj From simonmarhaskell at gmail.com Mon Oct 15 06:52:10 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Oct 15 06:50:32 2007 Subject: GHC benchmarks In-Reply-To: <87lka83e0j.fsf@nmd9999.imr.no> References: <87zlyqjaiz.fsf@nmd9999.imr.no> <470E2689.8040300@gmail.com> <87lka83e0j.fsf@nmd9999.imr.no> Message-ID: <4713465A.5090205@gmail.com> Ketil Malde wrote: > Simon Marlow writes: > >> Not so much code size, but data size (heap size, to be more >> precise). > > Of course. > > There was some talk about storing tags in pointers for 6.8, I couldn't > find the reference, but I wonder if that would help my situation? Unfortunately not, the pointer-tagging optimisation doesn't affect space usage, only runtime. >> It would be interesting to know how much time is spent in the GC - run >> the program with +RTS -sstderr. > > MUT time decreases a bit (131 to 127s) for x86_64, but GC time > increases a lot (98 to 179s). Right - GC time doubled, which is what we'd expect to see when the resident data size doubles. The decrease in MUT time is probably due to the extra registers available, but MUT time would also be affected by the increase in data size, because the cache hit rate should be lower. On the whole, I think these results are to be expected. There isn't much we can do to improve things in the short term, I'm afraid. Improvements in the pipeline will hopefully enable us to make better use of the extra registers on x86_64, and perhaps parallel GC in the future will get that GC time down again. Cheers, Simon From bbr at informatik.uni-kiel.de Mon Oct 15 10:51:17 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Mon Oct 15 11:13:06 2007 Subject: Prevent optimization from tempering with unsafePerformIO Message-ID: <47137E65.5050905@informatik.uni-kiel.de> Hello, I am writing a compiler from the functional logic language Curry to Haskell. As the result is a real extension of Haskell, there has to be SOME side effect involved. Unfortunately, this seems to prevent me from using any of ghc's optimizations on the resulting code. I have tried for some time to invoke the no-inline pragmata, but they seem to have no effect at all. Recently at ICFP, Neil Mitchell told me that there definitely is a way to avoid this problem. But does anybody know how? Thanks for your help! Bernd Brassel From bbr at informatik.uni-kiel.de Mon Oct 15 11:21:35 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Mon Oct 15 11:32:23 2007 Subject: Prevent optimization from tempering with unsafePerformIO Message-ID: <4713857F.9010105@informatik.uni-kiel.de> Hello, I am writing a compiler from the functional logic language Curry to Haskell. As the result is a real extension of Haskell, there has to be SOME side effect involved. Unfortunately, this seems to prevent me from using any of ghc's optimizations on the resulting code. I have tried for some time to invoke the no-inline pragmata, but they seem to have no effect at all. Recently at ICFP, Neil Mitchell told me that there definitely is a way to avoid this problem. But does anybody know how? Thanks for your help! Bernd Brassel From ndmitchell at gmail.com Mon Oct 15 11:34:53 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Oct 15 11:33:08 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <47137E65.5050905@informatik.uni-kiel.de> References: <47137E65.5050905@informatik.uni-kiel.de> Message-ID: <404396ef0710150834y66275048mc8dc10d28b328a43@mail.gmail.com> Hi Bernd, > I am writing a compiler from the functional logic language Curry to > Haskell. As the result is a real extension of Haskell, there has to be > SOME side effect involved. Unfortunately, this seems to prevent me from > using any of ghc's optimizations on the resulting code. I have tried for > some time to invoke the no-inline pragmata, but they seem to have no > effect at all. Recently at ICFP, Neil Mitchell told me that there > definitely is a way to avoid this problem. But does anybody know how? It varies by each piece of code, can you post a code fragment that gets optimised in the wrong way? In the particular case I was fighting with previously, GHC was not inlining the unsafe bit, but was floating out the actual computation and turning it into a CAF which was being shared. Thanks Neil From dons at galois.com Mon Oct 15 11:40:19 2007 From: dons at galois.com (Don Stewart) Date: Mon Oct 15 11:38:36 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4713857F.9010105@informatik.uni-kiel.de> References: <4713857F.9010105@informatik.uni-kiel.de> Message-ID: <20071015154019.GA29491@scytale.galois.com> bbr: > Hello, > > I am writing a compiler from the functional logic language Curry to > Haskell. As the result is a real extension of Haskell, there has to be > SOME side effect involved. Unfortunately, this seems to prevent me from > using any of ghc's optimizations on the resulting code. I have tried for > some time to invoke the no-inline pragmata, but they seem to have no > effect at all. Recently at ICFP, Neil Mitchell told me that there > definitely is a way to avoid this problem. But does anybody know how? > > Thanks for your help! > Bernd Brassel Can you give a specific example of what you have tried to do, and how it failed? Thanks, Don From bbr at informatik.uni-kiel.de Tue Oct 16 10:06:26 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Tue Oct 16 10:10:15 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <20071015154019.GA29491@scytale.galois.com> References: <4713857F.9010105@informatik.uni-kiel.de> <20071015154019.GA29491@scytale.galois.com> Message-ID: <4714C562.4060902@informatik.uni-kiel.de> Hi Neil, hi Don! Nice meeting you at ICFP by the way. > Can you give a specific example of what you have tried to do, and how it > failed? I have attached a short synopsis of what our Curry to Haskell conceptually does. I could explain what all the parts mean and why they are defined this way, if it is important. On first glance it looks as if we were doing unsafe things in the very worst way. But the invariants within the generated code clean up things again. E.g., the result of main does not at all depend on whether or not the program is evaluated eagerly or lazily. I hope it is okay that I did not add any no-inline pragmata or something like that. Unfortunately, I forgot all the things we have tried more than a year ago to make optimization work. But this is the way it should work: $ ghc --make -O0 -o curry-no-opt curry.hs [1 of 1] Compiling Main ( curry.hs, curry.o ) Linking curry-no-opt ... $ curry-no-opt 3 possibilities: [True,True,False] 2 possibilities: [True,False] and this is what happens after optimization: $ rm curry.hi curry.o $ ghc --make -O2 -o curry-opt curry.hs [1 of 1] Compiling Main ( curry.hs, curry.o ) Linking curry-opt ... $ curry-opt 3 possibilities: [True,False] 2 possibilities: [True,False] As the code is now that is no surprise. But how can I prevent this from happening by adding pragmata? Thanks a lot for your time! Bernd -------------- next part -------------- A non-text attachment was scrubbed... Name: curry.hs Type: text/x-haskell Size: 1622 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071016/a8ce9ff0/curry.bin From bbr at informatik.uni-kiel.de Tue Oct 16 10:15:31 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Tue Oct 16 10:27:25 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <404396ef0710150834y66275048mc8dc10d28b328a43@mail.gmail.com> References: <47137E65.5050905@informatik.uni-kiel.de> <404396ef0710150834y66275048mc8dc10d28b328a43@mail.gmail.com> Message-ID: <4714C783.1060901@informatik.uni-kiel.de> Neil Mitchell schrieb: > It varies by each piece of code, can you post a code fragment that > gets optimised in the wrong way? Sorry for posting this twice! I have added the code to the other thread. Thanks! Bernd From sabel at ki.informatik.uni-frankfurt.de Tue Oct 16 12:01:25 2007 From: sabel at ki.informatik.uni-frankfurt.de (David Sabel) Date: Tue Oct 16 12:00:53 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4714C562.4060902@informatik.uni-kiel.de> References: <4713857F.9010105@informatik.uni-kiel.de> <20071015154019.GA29491@scytale.galois.com> <4714C562.4060902@informatik.uni-kiel.de> Message-ID: <4714E055.8010106@ki.informatik.uni-frankfurt.de> Hi, I think it's the let floating (out) together with common subexpression elimination: > ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs [1 of 1] Compiling Main ( curry.hs, curry.o ) Linking curry-no-cse ... > ghc --make -O2 -no-recomp -fno-full-laziness -o curry-no-fll curry.hs [1 of 1] Compiling Main ( curry.hs, curry.o ) Linking curry-no-fll ... > ghc --make -O2 -no-recomp -fno-full-laziness -fno-cse -o curry-no-cse-no-fll curry.hs [1 of 1] Compiling Main ( curry.hs, curry.o ) Linking curry-no-cse-no-fll ... > ./curry-no-cse 3 possibilities: [True,False] 2 possibilities: [True,False] > ./curry-no-fll 3 possibilities: [True,False] 2 possibilities: [True,False] > ./curry-no-cse-no-fll 3 possibilities: [True,True,False] 2 possibilities: [True,False] Regards, David ps.: Maybe it is interesting to look at HasFuse [1] (somewhat outdated), but it exactly forbids both transformations [1] http://www.ki.informatik.uni-frankfurt.de/research/diamond/hasfuse/ Bernd Brassel wrote: > Hi Neil, hi Don! > > Nice meeting you at ICFP by the way. > > >> Can you give a specific example of what you have tried to do, and how it >> failed? >> > > I have attached a short synopsis of what our Curry to Haskell > conceptually does. I could explain what all the parts mean and why they > are defined this way, if it is important. On first glance it looks > as if we were doing unsafe things in the very worst way. But the > invariants within the generated code clean up things again. E.g., the > result of main does not at all depend on whether or not the program is > evaluated eagerly or lazily. > > I hope it is okay that I did not add any no-inline pragmata or something > like that. Unfortunately, I forgot all the things we have tried more > than a year ago to make optimization work. > > But this is the way it should work: > > $ ghc --make -O0 -o curry-no-opt curry.hs > [1 of 1] Compiling Main ( curry.hs, curry.o ) > Linking curry-no-opt ... > $ curry-no-opt > 3 possibilities: [True,True,False] > 2 possibilities: [True,False] > > and this is what happens after optimization: > > $ rm curry.hi curry.o > $ ghc --make -O2 -o curry-opt curry.hs > [1 of 1] Compiling Main ( curry.hs, curry.o ) > Linking curry-opt ... > $ curry-opt > 3 possibilities: [True,False] > 2 possibilities: [True,False] > > As the code is now that is no surprise. But how can I prevent this from > happening by adding pragmata? > > Thanks a lot for your time! > > Bernd > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From stefanor at cox.net Tue Oct 16 16:32:31 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 16 16:30:42 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4714C562.4060902@informatik.uni-kiel.de> References: <4713857F.9010105@informatik.uni-kiel.de> <20071015154019.GA29491@scytale.galois.com> <4714C562.4060902@informatik.uni-kiel.de> Message-ID: <20071016203231.GA3363@localhost.localdomain> On Tue, Oct 16, 2007 at 04:06:26PM +0200, Bernd Brassel wrote: > Hi Neil, hi Don! > > Nice meeting you at ICFP by the way. > > > Can you give a specific example of what you have tried to do, and how it > > failed? > > I have attached a short synopsis of what our Curry to Haskell > conceptually does. I could explain what all the parts mean and why they > are defined this way, if it is important. On first glance it looks > as if we were doing unsafe things in the very worst way. But the > invariants within the generated code clean up things again. E.g., the > result of main does not at all depend on whether or not the program is > evaluated eagerly or lazily. > > I hope it is okay that I did not add any no-inline pragmata or something > like that. Unfortunately, I forgot all the things we have tried more > than a year ago to make optimization work. Might I suggest, that the problem is your use of unsafePerformIO? If you use unsafePerformIO in accordance with the rules listed in the specification (which happens to be the FFI addendum), -O options will have no effect. (Not that what you are trying to do is achievable with correct use of unsafePerformIO; why do you want to do this unsafely, instead of just using 'length'? unsafePerformIO is a very slow function, remember) 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/20071016/10062c72/attachment.bin From bbr at informatik.uni-kiel.de Wed Oct 17 03:40:42 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Wed Oct 17 03:45:14 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <20071016203231.GA3363@localhost.localdomain> References: <4713857F.9010105@informatik.uni-kiel.de> <20071015154019.GA29491@scytale.galois.com> <4714C562.4060902@informatik.uni-kiel.de> <20071016203231.GA3363@localhost.localdomain> Message-ID: <4715BC7A.1000002@informatik.uni-kiel.de> Hi Stefan! Thanks for your answer. Stefan O'Rear wrote: > Might I suggest, that the problem is your use of unsafePerformIO? Yes you might. And you are surely right. But not using it in this way is not an alternative. > why do you want to do this unsafely, > instead of just using 'length'? unsafePerformIO is a very slow > function, remember) The big picture is that we generate programs like this example in order to compile the functional logic language Curry down to Haskell. Basically, there are two ways to do this: a) write an interpreter for Curry in Haskell, e.g., by employing non-determinism monads b) extend Haskell by employing side effects Alternative a) is not really an issue for us. Doing it this way, all Curry programs will suffer in performance in such a magnitude that - in comparison - unsafePerformIO is super-fast. In addition, we already have interpreters for Curry which I do not assume a Haskell interpreter to outperform without 5 years worth of tuning. Alternative b) is the choice, because doing it this way, all deterministic, i.e., purely functional parts of Curry programs would take advantage of Haskell being a functional language. If then the logic parts are not so fast, e.g., because unsafePerformIO is slow, this does not matter so much. In comparison to other approaches (like Alternative a) and many other implementations of Curry) our slogan is: "make functions fast and logic possible". Fast functions will outweigh the slowdown for logics. But to get "functions fast" employing optimization sounds like a good idea to me. But even without any optimization, our system can compare well to most other implementations for many applications. Thanks for your input! Bernd From bbr at informatik.uni-kiel.de Wed Oct 17 04:02:14 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Wed Oct 17 04:18:51 2007 Subject: Prevent optimization from tempering with unsafePerformIO References: 4714C562.4060902@informatik.uni-kiel.de Message-ID: <4715C186.5080404@informatik.uni-kiel.de> Hi David, thank you! This is really useful information! > I think it's the let floating (out) together with common subexpression > elimination: > > > ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs > [1 of 1] Compiling Main ( curry.hs, curry.o ) > Linking curry-no-cse ... > > ghc --make -O2 -no-recomp -fno-full-laziness -o curry-no-fll curry.hs > [1 of 1] Compiling Main ( curry.hs, curry.o ) > Linking curry-no-fll ... > > ghc --make -O2 -no-recomp -fno-full-laziness -fno-cse -o > curry-no-cse-no-fll curry.hs > [1 of 1] Compiling Main ( curry.hs, curry.o ) > Linking curry-no-cse-no-fll ... > > ./curry-no-cse > 3 possibilities: [True,False] > 2 possibilities: [True,False] > > ./curry-no-fll > 3 possibilities: [True,False] > 2 possibilities: [True,False] > > ./curry-no-cse-no-fll > 3 possibilities: [True,True,False] > 2 possibilities: [True,False] I will try this on large scale Curry programs. I hope the remaining optimizations will still do some good. Do you think that there is a way to be more selective? I mean to select those parts of the program which can and which cannot be optimized? > ps.: Maybe it is interesting to look at HasFuse [1] (somewhat outdated), > but it exactly forbids both transformations > > [1] http://www.ki.informatik.uni-frankfurt.de/research/diamond/hasfuse/ Yes, that looks interesting, too. Are there plans to update it with the ghc? Thanks for your hints! Bernd From josef.svenningsson at gmail.com Wed Oct 17 05:05:54 2007 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Wed Oct 17 05:04:04 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4715BC7A.1000002@informatik.uni-kiel.de> References: <4713857F.9010105@informatik.uni-kiel.de> <20071015154019.GA29491@scytale.galois.com> <4714C562.4060902@informatik.uni-kiel.de> <20071016203231.GA3363@localhost.localdomain> <4715BC7A.1000002@informatik.uni-kiel.de> Message-ID: <8dde104f0710170205m56473b27ne5cca92098f15802@mail.gmail.com> On 10/17/07, Bernd Brassel wrote: > > why do you want to do this unsafely, > > instead of just using 'length'? unsafePerformIO is a very slow > > function, remember) > > The big picture is that we generate programs like this example in order > to compile the functional logic language Curry down to Haskell. > Basically, there are two ways to do this: > > a) write an interpreter for Curry in Haskell, e.g., by employing > non-determinism monads > b) extend Haskell by employing side effects > > Alternative a) is not really an issue for us. Doing it this way, all > Curry programs will suffer in performance in such a magnitude that - in > comparison - unsafePerformIO is super-fast. In addition, we already have > interpreters for Curry which I do not assume a Haskell interpreter to > outperform without 5 years worth of tuning. > > Alternative b) is the choice, because doing it this way, all > deterministic, i.e., purely functional parts of Curry programs would > take advantage of Haskell being a functional language. If then the logic > parts are not so fast, e.g., because unsafePerformIO is slow, this does > not matter so much. In comparison to other approaches (like Alternative > a) and many other implementations of Curry) our slogan is: "make > functions fast and logic possible". Fast functions will outweigh the > slowdown for logics. But to get "functions fast" employing optimization > sounds like a good idea to me. But even without any optimization, our > system can compare well to most other implementations for many > applications. > May I suggest a third route that has the advantages of both your approaches. The backside is of course that it takes a bit of work. My suggestion is to do an effect analysis of your curry programs to identify the purely functional parts and compile them directly to pure Haskell. The rest of the programs can run in a monad. This approach should be more robust than relying on unsafePerformIO. It is also very much in the spirit of your slogan. Just my 2 cents, /Josef From sabel at ki.informatik.uni-frankfurt.de Wed Oct 17 05:07:37 2007 From: sabel at ki.informatik.uni-frankfurt.de (David Sabel) Date: Wed Oct 17 05:06:58 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4715C186.5080404@informatik.uni-kiel.de> References: 4714C562.4060902@informatik.uni-kiel.de <4715C186.5080404@informatik.uni-kiel.de> Message-ID: <4715D0D9.8010002@ki.informatik.uni-frankfurt.de> Hi Bernd, Bernd Brassel wrote: > Hi David, > > thank you! This is really useful information! > > >> I think it's the let floating (out) together with common subexpression >> elimination: >> >> > ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs >> [1 of 1] Compiling Main ( curry.hs, curry.o ) >> Linking curry-no-cse ... >> > ghc --make -O2 -no-recomp -fno-full-laziness -o curry-no-fll curry.hs >> [1 of 1] Compiling Main ( curry.hs, curry.o ) >> Linking curry-no-fll ... >> > ghc --make -O2 -no-recomp -fno-full-laziness -fno-cse -o >> curry-no-cse-no-fll curry.hs >> [1 of 1] Compiling Main ( curry.hs, curry.o ) >> Linking curry-no-cse-no-fll ... >> > ./curry-no-cse >> 3 possibilities: [True,False] >> 2 possibilities: [True,False] >> > ./curry-no-fll >> 3 possibilities: [True,False] >> 2 possibilities: [True,False] >> > ./curry-no-cse-no-fll >> 3 possibilities: [True,True,False] >> 2 possibilities: [True,False] >> > > I will try this on large scale Curry programs. I hope the remaining > optimizations will still do some good. Do you think that there is a way > to be more selective? I mean to select those parts of the program which > can and which cannot be optimized? > I think this would require an analysis of the code during compilation (to split into "pure" parts and "impure" parts), but we did not investigate this. > >> ps.: Maybe it is interesting to look at HasFuse [1] (somewhat outdated), >> but it exactly forbids both transformations >> >> [1] http://www.ki.informatik.uni-frankfurt.de/research/diamond/hasfuse/ >> > > Yes, that looks interesting, too. Are there plans to update it with the > ghc? > Honestly, we did nothing since 2004 on the code, but maybe we could port the changes to the current source of ghc. I remember that in an early version of ghc (I think < 5) there was an option -O file which gave the user control over the optimizations with a script, this would probably a nice feature to have again... Regards, David > Thanks for your hints! > Bernd > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From simonpj at microsoft.com Wed Oct 17 05:41:21 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 17 05:39:32 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4715C186.5080404@informatik.uni-kiel.de> References: 4714C562.4060902@informatik.uni-kiel.de <4715C186.5080404@informatik.uni-kiel.de> Message-ID: I think you'll find it useful to be explicit about what you are relying on. For example I think that if your program contains two calls unsafePerformIO e1 unsafePerformIO e2 then * You don't care about the *order* in which these are performed * You do care that they are both performed separately, even if e1=e2. That is, you do not want CSE (common sub-expression) * I'm not sure whether you care if they are not performed at all. E.g. if you have let x = unsafePerformIO e in True then GHC will discard the binding for x. You can control this by adding data dependencies, so that the body of the 'let' depends on 'x'. * I'm not sure if you care whether they are performed once or many times. E.g. f = \x. x + unsafePerformIO (h z) If the (h z) doesn't mention 'x', GHC will transform this to v = unsafePerformIO (h z) f = \x. x+v So now the effect happens once only, rather than once per call of f. Again you can control this by adding an articifical dependency on x. Adding these artificial dependencies may amount to exactly the kind of effect analysis that Joesef suggests. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Bernd Brassel | Sent: 17 October 2007 09:02 | To: glasgow-haskell-users@haskell.org | Subject: Prevent optimization from tempering with unsafePerformIO | | Hi David, | | thank you! This is really useful information! | | > I think it's the let floating (out) together with common subexpression | > elimination: | > | > > ghc --make -O2 -no-recomp -fno-cse -o curry-no-cse curry.hs | > [1 of 1] Compiling Main ( curry.hs, curry.o ) | > Linking curry-no-cse ... | > > ghc --make -O2 -no-recomp -fno-full-laziness -o curry-no-fll curry.hs | > [1 of 1] Compiling Main ( curry.hs, curry.o ) | > Linking curry-no-fll ... | > > ghc --make -O2 -no-recomp -fno-full-laziness -fno-cse -o | > curry-no-cse-no-fll curry.hs | > [1 of 1] Compiling Main ( curry.hs, curry.o ) | > Linking curry-no-cse-no-fll ... | > > ./curry-no-cse | > 3 possibilities: [True,False] | > 2 possibilities: [True,False] | > > ./curry-no-fll | > 3 possibilities: [True,False] | > 2 possibilities: [True,False] | > > ./curry-no-cse-no-fll | > 3 possibilities: [True,True,False] | > 2 possibilities: [True,False] | | I will try this on large scale Curry programs. I hope the remaining | optimizations will still do some good. Do you think that there is a way | to be more selective? I mean to select those parts of the program which | can and which cannot be optimized? | | > ps.: Maybe it is interesting to look at HasFuse [1] (somewhat outdated), | > but it exactly forbids both transformations | > | > [1] http://www.ki.informatik.uni-frankfurt.de/research/diamond/hasfuse/ | | Yes, that looks interesting, too. Are there plans to update it with the | ghc? | | Thanks for your hints! | Bernd | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From bbr at informatik.uni-kiel.de Wed Oct 17 07:24:36 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Wed Oct 17 07:28:46 2007 Subject: Prevent optimization from tempering with unsafePerformIO References: 4715BC7A.1000002@informatik.uni-kiel.de Message-ID: <4715F0F4.90605@informatik.uni-kiel.de> > May I suggest a third route that has the advantages of both your > approaches. The backside is of course that it takes a bit of work. My > suggestion is to do an effect analysis of your curry programs to > identify the purely functional parts and compile them directly to pure > Haskell. The rest of the programs can run in a monad. This approach > should be more robust than relying on unsafePerformIO. It is also very > much in the spirit of your slogan. Thank you for the suggestion. We were thinking along the lines of identifying "the purely functional parts and compile them directly to pure Haskell" as a possibility of optimization (with some code duplication). But if the "rest of the programs can run in a monad" the question is: How much of the example program I submitted would you classify as "purely functional"? Actually, most of it is purely functional apart from the (?) - operator. But I do not see a way to make use of this. If, however, the whole program is classified as "non-functional" then this is definitely not in the spirit of the slogan. One effect we like very much about our implementation is that all expressions which do not depend on non-deterministic values are shared across the whole search. Note, that this dependence is a dynamic property. If the code of programs like the example was monadic, I do not see how not to loose this property. Thanks again! Bernd From bbr at informatik.uni-kiel.de Wed Oct 17 07:44:03 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Wed Oct 17 08:01:59 2007 Subject: Prevent optimization from tempering with unsafePerformIO References: 4715C186.5080404@informatik.uni-kiel.de Message-ID: <4715F583.5040202@informatik.uni-kiel.de> > I think you'll find it useful to be explicit about what you are relying on. Yes, good point. > For example I think that if your program contains two calls > unsafePerformIO e1 > unsafePerformIO e2 > then > * You don't care about the *order* in which these are performed Right, the order is not important. > * You do care that they are both performed separately, even if > e1=e2. That is, you do not want CSE (common sub-expression) Right. > * I'm not sure whether you care if they are not performed at all. > E.g. if you have > let x = unsafePerformIO e in True I do not care whether or not the action is performed. Even more so, if the whole evaluation strategy is not lazy but speculatively eager or something the like, this does not change the semantics of our programs. > * I'm not sure if you care whether they are performed once or > many times. E.g. > f = \x. x + unsafePerformIO (h z) > If the (h z) doesn't mention 'x', GHC will transform this to > v = unsafePerformIO (h z) > f = \x. x+v > So now the effect happens once only, rather than once per > call of f. Again you can control this by adding an articifical > dependency on x. This is a very good example. The effect has to happen once per call to f. So what do you mean by "adding an artificial dependency"? Would for this example something like the following be enough? f = \x. x + myEffect x myEffect _ = unsafePerformIO (h z) > Adding these artificial dependencies may amount to exactly the kind > of effect analysis that Joesef suggests. Yes such a determinism analysis is a good idea to optimize functional logic programs and we have already done work in that direction. But I would not like to turn those programs into a monad which we cannot prove to be deterministic. Your hint of "adding artificial dependencies" sounds more promising. The hints and suggestions I got in this thread are already very helpful, thanks for that! Bernd From ahey at iee.org Wed Oct 17 09:02:58 2007 From: ahey at iee.org (Adrian Hey) Date: Wed Oct 17 09:01:05 2007 Subject: Orphan Instances with GHC 6.8 Message-ID: <47160802.3000309@iee.org> Hello Folks, One thing different from 6.6 and 6.8 is I find that with -Wall I get a lot more warnings about orphan instances, even if the code has not changed. Has the definition of what an Orphan instance is changed? Or is this a bug? If so, is the bug in 6.6 or 6.8? I can make them go away with the -fno-warn-orphans flag, but I'm still curious as to why I didn't have to do this before. Thanks -- Adrian Hey From igloo at earth.li Wed Oct 17 09:11:23 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 17 09:09:32 2007 Subject: ANNOUNCE: GHC 6.8.1 Second Release Candidate Message-ID: <20071017131123.GA28173@matrix.chaos.earth.li> We are pleased to announce the Second Release Candidate phase for GHC 6.8.1. The 6.8.1 release is very close now. We only intend to look at the bugs listed here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.1&order=priority so if you think there is something important that is not listed there then this is the time to shout! You can get 6.8.1 snapshots to test from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071015-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.0.20071015-src-extralibs.tar.bz2 Only the first of these is necessary. The "extralibs" package contains various extra packages that are sometimes supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also binary distributions for x86_64/Linux and i386/Linux, and an installer for Windows. Please test as much as possible, bugs are much cheaper if we find them before the release! We expect to release later this month. Thanks Ian, on behalf of the GHC team From isaacdupree at charter.net Wed Oct 17 10:45:21 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Oct 17 10:44:49 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4715F583.5040202@informatik.uni-kiel.de> References: 4715C186.5080404@informatik.uni-kiel.de <4715F583.5040202@informatik.uni-kiel.de> Message-ID: <47162001.6090102@charter.net> Bernd Brassel wrote: >> * I'm not sure if you care whether they are performed once or >> many times. E.g. >> f = \x. x + unsafePerformIO (h z) >> If the (h z) doesn't mention 'x', GHC will transform this to >> v = unsafePerformIO (h z) >> f = \x. x+v >> So now the effect happens once only, rather than once per >> call of f. Again you can control this by adding an articifical >> dependency on x. > > This is a very good example. The effect has to happen once per call to f. > > So what do you mean by "adding an artificial dependency"? Would for this > example something like the following be enough? > > f = \x. x + myEffect x > > myEffect _ = unsafePerformIO (h z) > >> Adding these artificial dependencies may amount to exactly the kind >> of effect analysis that Joesef suggests. > > Yes such a determinism analysis is a good idea to optimize functional > logic programs and we have already done work in that direction. But I > would not like to turn those programs into a monad which we cannot prove > to be deterministic. Your hint of "adding artificial dependencies" > sounds more promising. perhaps unsafePerformIODependingOn :: dep -> IO a -> a {-# NOINLINE unsafePerformIODependingOn #-} --is that pragma enough to avoid strictness/unused-ness analysis? --use 'lazy'? compile the module this is defined in with -O0? --I don't think seq'ing dep is desired. unsafePerformIODependingOn dep a = unsafePerformIO a f = \x. x + unsafePerformIODependingOn (x) (h z) --use a tuple if there are multiple variables you depend on also, do you care if the same `unsafePerformIO` is repeatedly performed more than once for no reason? Isaac From claus.reinke at talk21.com Wed Oct 17 11:19:03 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed Oct 17 11:17:16 2007 Subject: ANNOUNCE: GHC 6.8.1 Second Release Candidate References: <20071017131123.GA28173@matrix.chaos.earth.li> Message-ID: <018a01c810d1$0e4632f0$40458351@cr3lt> > The 6.8.1 release is very close now. We only intend to look at the bugs > listed here: > > > http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.1&order=priority > > so if you think there is something important that is not listed there > then this is the time to shout! comparing that list against the full by-milestone list: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=milestone&order=priority reveals several oddities: - the list of outstanding issues for 6.8 branch is suspiciously long. has this been reviewed in detail? several of the tickets look more or less fixed, and there seems to be nothing standing in the way for fixing some more, such as this one: http://hackage.haskell.org/trac/ghc/ticket/1226 - several tickets seem to be stuck in nirvana, and should be reviewed: - since there'll be a 6.8.1 instead of a 6.6.2, all the tickets in that milestone need review. some may be fixed in 6.8.1, some have never been touched, such as this one http://hackage.haskell.org/trac/ghc/ticket/1216 - there is a whole bunch of tickets without milestone! shouldn't they be reviewed and milestoned at least, before making any releases? no tickets should be left in those two groups by the time of release, i think? since so many tickets have no owner, it would be useful to have an extra field, giving the date/milestone of last revision (even if there is no owner, all tickets get reviewed when they come in, i guess, and again every time a release comes up, to decide whether to handle them now or to move their milestone). that way, one could check easily which tickets have skipped the radar completely, or which tickets have been reviewed (not necessarily fixed) for a particular release. perhaps that could be another value for the status field (new: no one has looked into it; assigned: someone has actually taken it; reviewed date: someone has acknowledged the ticket; etc.)? claus From ahey at iee.org Wed Oct 17 12:03:54 2007 From: ahey at iee.org (Adrian Hey) Date: Wed Oct 17 12:02:02 2007 Subject: Orphan Instances with GHC 6.8 In-Reply-To: <47160802.3000309@iee.org> References: <47160802.3000309@iee.org> Message-ID: <4716326A.2070308@iee.org> Hello again, Adrian Hey wrote: > Hello Folks, > > One thing different from 6.6 and 6.8 is I find that with -Wall > I get a lot more warnings about orphan instances, even if the > code has not changed. > > Has the definition of what an Orphan instance is changed? > > Or is this a bug? If so, is the bug in 6.6 or 6.8? > > I can make them go away with the -fno-warn-orphans flag, > but I'm still curious as to why I didn't have to do this before. Sorry, this situation seems more complex than this. I can't quite figure out whats going on, in fact this but it may to be related to some other change I've made in the code to get since 6.8. The strange thing (to me) is that if I take exactly the same module and use it in 2 different packages (which are compiled with the same ghc options AFAIK), one gives me the orphan warning and one doesn't. Does that make sense? (I.E. Is "Orphanness" somehow context dependent?) Thanks -- Adrian Hey From simonpj at microsoft.com Wed Oct 17 12:24:17 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 17 12:22:35 2007 Subject: Orphan Instances with GHC 6.8 In-Reply-To: <4716326A.2070308@iee.org> References: <47160802.3000309@iee.org> <4716326A.2070308@iee.org> Message-ID: What you say rings no bells. I don't see how to make progress without more info. Perhaps show the module that elicits the unexpected orphan message? Simon | -----Original Message----- | From: Adrian Hey [mailto:ahey@iee.org] | Sent: 17 October 2007 17:04 | To: glasgow-haskell-users@haskell.org; Simon Peyton-Jones | Subject: Re: Orphan Instances with GHC 6.8 | | Hello again, | | Adrian Hey wrote: | > Hello Folks, | > | > One thing different from 6.6 and 6.8 is I find that with -Wall | > I get a lot more warnings about orphan instances, even if the | > code has not changed. | > | > Has the definition of what an Orphan instance is changed? | > | > Or is this a bug? If so, is the bug in 6.6 or 6.8? | > | > I can make them go away with the -fno-warn-orphans flag, | > but I'm still curious as to why I didn't have to do this before. | | Sorry, this situation seems more complex than this. I can't quite | figure out whats going on, in fact this but it may to be related | to some other change I've made in the code to get since 6.8. | | The strange thing (to me) is that if I take exactly the same module | and use it in 2 different packages (which are compiled with the same | ghc options AFAIK), one gives me the orphan warning and one doesn't. | Does that make sense? (I.E. Is "Orphanness" somehow context dependent?) | | Thanks | -- | Adrian Hey From g9ks157k at acme.softbase.org Wed Oct 17 12:57:01 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Oct 17 12:55:20 2007 Subject: type families not advertised for 6.8 Message-ID: <200710171857.02098.g9ks157k@acme.softbase.org> Hello, on I read: ?we are not advertising type equalities for 6.8?. What does this mean? Is it possible that type family support will be removed from GHC at some point? Best wishes, Wolfgang From simonpj at microsoft.com Wed Oct 17 13:07:41 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 17 13:05:50 2007 Subject: type families not advertised for 6.8 In-Reply-To: <200710171857.02098.g9ks157k@acme.softbase.org> References: <200710171857.02098.g9ks157k@acme.softbase.org> Message-ID: | on I read: ?we are | not advertising type equalities for 6.8?. What does this mean? Is it | possible that type family support will be removed from GHC at some point? Absolutely not; quite the reverse. It means that some of the *code* for type functions happens to be in the 6.8 release --- but that code has bugs. It's only in 6.8 for our convenience (to avoid too great a divergence between the HEAD and 6.8), but we do not plan to *support* type functions in 6.8. Doing that would delay 6.8 by 3 months. Instead we are working hard on making type functions work in the HEAD. Simon From mechvel at botik.ru Wed Oct 17 13:31:51 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Oct 17 13:29:57 2007 Subject: empty export warning Message-ID: <20071017173151.GA22908@scico.botik.ru> People, here is a more precise report about empty _export_ in ghc-6.8.1-candidate: I use -------------------------------- module M1 (f, module M2) where import M2 () f = ... -------------------------------- in the situation when M1 imports some instances from M2 and reexports these instances. And ghc-6.8.1-candidate reports "Warning: The export item `module M2' exports nothing" 1) Can I fix anything here? 2) Should this warning be different? Regards, ----------------- Serge Mechveliani mechvel@botik.ru From ahey at iee.org Wed Oct 17 13:32:45 2007 From: ahey at iee.org (Adrian Hey) Date: Wed Oct 17 13:30:52 2007 Subject: Orphan Instances with GHC 6.8 In-Reply-To: References: <47160802.3000309@iee.org> <4716326A.2070308@iee.org> Message-ID: <4716473D.2080306@iee.org> Hello Simon Simon Peyton-Jones wrote: > What you say rings no bells. I don't see how to make progress without more info. > Perhaps show the module that elicits the unexpected orphan message? The problem I'm having is with collections-package.. http://darcs.haskell.org/packages/collections-ghc6.6/ but, it's complicated by the fact that.. 1- The code I'm working on is my local repository (which amongst other things) has some changes in it to get it to compile with 6.8 (experimentally), so is not quite the same. 2- I can't get exactly the same code to compile with the different ghc versions. 3- Every experiment I try takes a long time because the collections package takes a long time to build. 4- I'm a bit busy today :-) So I'm afraid I can't provide a small demo of the problem because I'm having a hard time reproducing it consistently. But I'll try to get to produce some kind of reproducible (but not necessarily small :-) test case soon. Or else just report this as a false alarm caused by me doing something silly :-) So maybe for the time being you should forget I mentioned this as I don't want to waste anybody's time. Thanks -- Adrian Hey > Simon > > | -----Original Message----- > | From: Adrian Hey [mailto:ahey@iee.org] > | Sent: 17 October 2007 17:04 > | To: glasgow-haskell-users@haskell.org; Simon Peyton-Jones > | Subject: Re: Orphan Instances with GHC 6.8 > | > | Hello again, > | > | Adrian Hey wrote: > | > Hello Folks, > | > > | > One thing different from 6.6 and 6.8 is I find that with -Wall > | > I get a lot more warnings about orphan instances, even if the > | > code has not changed. > | > > | > Has the definition of what an Orphan instance is changed? > | > > | > Or is this a bug? If so, is the bug in 6.6 or 6.8? > | > > | > I can make them go away with the -fno-warn-orphans flag, > | > but I'm still curious as to why I didn't have to do this before. > | > | Sorry, this situation seems more complex than this. I can't quite > | figure out whats going on, in fact this but it may to be related > | to some other change I've made in the code to get since 6.8. > | > | The strange thing (to me) is that if I take exactly the same module > | and use it in 2 different packages (which are compiled with the same > | ghc options AFAIK), one gives me the orphan warning and one doesn't. > | Does that make sense? (I.E. Is "Orphanness" somehow context dependent?) > | > | Thanks > | -- > | Adrian Hey > > > From josef.svenningsson at gmail.com Wed Oct 17 14:18:00 2007 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Wed Oct 17 14:16:09 2007 Subject: Prevent optimization from tempering with unsafePerformIO In-Reply-To: <4715F0F4.90605@informatik.uni-kiel.de> References: <4715F0F4.90605@informatik.uni-kiel.de> Message-ID: <8dde104f0710171118r5d1854b1n29ce8ffafff548ce@mail.gmail.com> Hi again, On 10/17/07, Bernd Brassel wrote: > > May I suggest a third route that has the advantages of both your > > approaches. The backside is of course that it takes a bit of work. My > > suggestion is to do an effect analysis of your curry programs to > > identify the purely functional parts and compile them directly to pure > > Haskell. The rest of the programs can run in a monad. This approach > > should be more robust than relying on unsafePerformIO. It is also very > > much in the spirit of your slogan. > > Thank you for the suggestion. We were thinking along the lines of > identifying "the purely functional parts and compile them directly to > pure Haskell" as a possibility of optimization (with some code > duplication). But if the "rest of the programs can run in a monad" the > question is: How much of the example program I submitted would you > classify as "purely functional"? Actually, most of it is purely > functional apart from the (?) - operator. But I do not see a way to make > use of this. If, however, the whole program is classified as > "non-functional" then this is definitely not in the spirit of the > slogan. One effect we like very much about our implementation is that > all expressions which do not depend on non-deterministic values are > shared across the whole search. I suspect that any reasonably precise analysis will classify all the pure functions in your example program as pure, i.e. ifThenElse, (|||), depthFirstSearch, dfs and choose. But which functions that will be classified as pure of course depends on the exact formulation of the analysis. Also, I could be wrong since I'm not 100% sure of the intended semantics of your examples. Some people who've looked into determinism analysis in detail is Ricardo Pe?a and Clara Segura, when working with the language Eden. You can find most of the relevant papers here: http://dalila.sip.ucm.es/miembros/clara/publications.html > Note, that this dependence is a dynamic > property. If the code of programs like the example was monadic, I do not > see how not to loose this property. > I'm not quite sure what you mean when you say that dependence is dynamic. > Simon Peyton Jones said: >> Adding these artificial dependencies may amount to exactly the kind >> of effect analysis that Josef suggests. > > Yes such a determinism analysis is a good idea to optimize functional > logic programs and we have already done work in that direction. But I > would not like to turn those programs into a monad which we cannot prove > to be deterministic. Your hint of "adding artificial dependencies" > sounds more promising. Don't take my suggestion of using monads too literally if you don't like monads. Indeed Simon's dependency injection can be formulated as a monad but you don't need to use monads if you don't want to. My point was that your programs will be divided into a pure part and an effectful part. Monads are just one way of capturing the effectfulness. Cheers, Josef From isaacdupree at charter.net Wed Oct 17 14:35:37 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Wed Oct 17 14:35:08 2007 Subject: empty export warning In-Reply-To: <20071017173151.GA22908@scico.botik.ru> References: <20071017173151.GA22908@scico.botik.ru> Message-ID: <471655F9.60806@charter.net> Serge D. Mechveliani wrote: > People, > > here is a more precise report about empty _export_ in > ghc-6.8.1-candidate: > > I use > -------------------------------- > module M1 (f, module M2) > where > import M2 () > f = ... > -------------------------------- > > in the situation when M1 imports some instances from M2 and > reexports these instances. > > And ghc-6.8.1-candidate reports > > "Warning: The export item `module M2' exports nothing" > > 1) Can I fix anything here? > 2) Should this warning be different? The warning is true. The instances will be exported even if `module M2' is omitted from the export list, so that export item exports nothing. Isaac From mechvel at botik.ru Wed Oct 17 16:04:43 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Wed Oct 17 16:02:47 2007 Subject: empty export warning In-Reply-To: <471655F9.60806@charter.net> References: <20071017173151.GA22908@scico.botik.ru> <471655F9.60806@charter.net> Message-ID: <20071017200443.GB26648@scico.botik.ru> On Wed, Oct 17, 2007 at 03:35:37PM -0300, Isaac Dupree wrote: > Serge D. Mechveliani wrote: > >People, > > > >here is a more precise report about empty _export_ in > >ghc-6.8.1-candidate: > > > >I use > > -------------------------------- > > module M1 (f, module M2) > > where > > import M2 () > > f = ... > > -------------------------------- > > > >in the situation when M1 imports some instances from M2 and > >reexports these instances. > > > >And ghc-6.8.1-candidate reports > > > > "Warning: The export item `module M2' exports nothing" > > > >1) Can I fix anything here? > >2) Should this warning be different? > > The warning is true. The instances will be exported even if `module M2' > is omitted from the export list, so that export item exports nothing. > I see. Thank you. ----------- Mechveliani From bernardy at chalmers.se Wed Oct 17 16:24:34 2007 From: bernardy at chalmers.se (Jean-Philippe Bernardy) Date: Wed Oct 17 16:22:44 2007 Subject: type families not advertised for 6.8 In-Reply-To: References: <200710171857.02098.g9ks157k@acme.softbase.org> Message-ID: <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> On 10/17/07, Simon Peyton-Jones wrote: > | on I read: "we are > | not advertising type equalities for 6.8". What does this mean? Is it > | possible that type family support will be removed from GHC at some point? > > Absolutely not; quite the reverse. It means that some of the *code* for type functions happens to be in the 6.8 release --- but that code has bugs. It's only in 6.8 for our convenience (to avoid too great a divergence between the HEAD and 6.8), but we do not plan to *support* type functions in 6.8. Doing that would delay 6.8 by 3 months. Do you make any difference between associated type synonyms and type functions in this respect? --JP From igloo at earth.li Wed Oct 17 16:47:53 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 17 16:46:03 2007 Subject: bug in 6.8.1-candidate In-Reply-To: <20070930151347.GA15803@scico.botik.ru> References: <20070930151347.GA15803@scico.botik.ru> Message-ID: <20071017204753.GA924@matrix.chaos.earth.li> Hi Serge, Thanks for the report! On Sun, Sep 30, 2007 at 07:13:47PM +0400, Serge D. Mechveliani wrote: > > http://botik.ru/pub/local/Mechveliani/ghcBugs/bug-6.8.0-sep28.zip > > ---------------------------------------------------- > ... > > GBasFld_.hs: ... > > ghc-6.8.0.20070928: panic! (the 'impossible' happened) > (GHC version 6.8.0.20070928 for i386-unknown-linux): > initC: srt_lbl > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I believe this is now fixed; with 6.8.0.20071016: [52 of 60] Compiling GBasFld_ ( GBasFld_.hs, dist/build/GBasFld_.o ) [53 of 60] Compiling GBasEuc_ ( GBasEuc_.hs, dist/build/GBasEuc_.o ) GBasEuc_.hs:40:15: Module `GBasFld_' does not export `cnAs_ev_' [...] Please let us know if you still have problems. Thanks Ian From igloo at earth.li Wed Oct 17 18:18:57 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 17 18:17:06 2007 Subject: ANNOUNCE: GHC 6.8.1 Second Release Candidate In-Reply-To: <018a01c810d1$0e4632f0$40458351@cr3lt> References: <20071017131123.GA28173@matrix.chaos.earth.li> <018a01c810d1$0e4632f0$40458351@cr3lt> Message-ID: <20071017221857.GA5035@matrix.chaos.earth.li> Hi Claus, On Wed, Oct 17, 2007 at 04:19:03PM +0100, Claus Reinke wrote: > >The 6.8.1 release is very close now. We only intend to look at the bugs > >listed here: > > > >http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&milestone=6.8.1&order=priority > > - the list of outstanding issues for 6.8 branch is suspiciously long. has > this been reviewed in detail? There are always more bugs and performance issues that could be fixed, but at some point we need to draw a line and make a release, or else we never will! We don't think that there is anything critical missing from the above list, but it's possible that either we've overlooked something, or there is something that is critical to some people but we haven't realised how important it is. Of course, we can't guarantee to fix everything that people raise (or we'd be back to never releasing), but if something jumps out at you please let us know and we will look at it. Thanks Ian From simonpj at microsoft.com Wed Oct 17 21:58:21 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 17 21:55:40 2007 Subject: type families not advertised for 6.8 In-Reply-To: <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> References: <200710171857.02098.g9ks157k@acme.softbase.org> <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> Message-ID: | > Absolutely not; quite the reverse. It means that some of the *code* for | type functions happens to be in the 6.8 release --- but that code has bugs. | It's only in 6.8 for our convenience (to avoid too great a divergence between | the HEAD and 6.8), but we do not plan to *support* type functions in 6.8. | Doing that would delay 6.8 by 3 months. | | Do you make any difference between associated type synonyms and type | functions in this respect? No difference: both are in the 6.8 code base, but we won't support them there. Both are in the HEAD, and we will support them there. (Associated data types have the same status -- but the 6.8 code for associated data types is quite a bit solider, so they'll probably work. No promises though!) Simon From chak at cse.unsw.edu.au Wed Oct 17 22:46:25 2007 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Oct 17 22:44:43 2007 Subject: type families not advertised for 6.8 In-Reply-To: <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> References: <200710171857.02098.g9ks157k@acme.softbase.org> <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> Message-ID: <4716C901.4010701@cse.unsw.edu.au> Jean-Philippe Bernardy schrieb: > On 10/17/07, Simon Peyton-Jones wrote: >> | on I read: "we are >> | not advertising type equalities for 6.8". What does this mean? Is it >> | possible that type family support will be removed from GHC at some point? >> >> Absolutely not; quite the reverse. It means that some of the *code* for type functions happens to be in the 6.8 release --- but that code has bugs. It's only in 6.8 for our convenience (to avoid too great a divergence between the HEAD and 6.8), but we do not plan to *support* type functions in 6.8. Doing that would delay 6.8 by 3 months. > > Do you make any difference between associated type synonyms and type > functions in this respect? No. Associated type synonyms are essentially just syntactic sugar for toplevel type families. They are not distinguished during type checking. The rationale for not officially supporting type families (and associated type synonyms and equality constraints) for 6.8 is that the code implementing them in GHC is (a) pretty new and still has a number of known bugs which will take a while to shake out and (b) is currently not well integrated with some other language features (most notably GADTs). Fixing (a) and especially (b) will involve some rather significant changes to GHC's typechecker - too significant for changes in a stable branch. On the other hand, as Simon says, waiting with 6.8 until all this has stabilised would delay 6.8 too much. In any case, I am committed to removing all outstanding problems with type families in the HEAD as quickly as possible. Manuel From mechvel at botik.ru Thu Oct 18 03:28:19 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Oct 18 03:26:25 2007 Subject: -O bug? Message-ID: <20071018072819.GA2239@scico.botik.ru> Dear GHC developers, The point (1) below looks like a bug (in all GHC versions!). (1) -O for demo-test. Take (the public) docon-2.10 build it under -O, install, and build also under -O its test program by cd demotest ghc $doconCpOpt -O --make Main Either the latter compilation will loop forever or it will take an unnaturally large resource. Yes, the functions T_.test, T_tt are defined in rather a particular way (see them). I always build this test under -Onot, because compiling with optimization has not much sense for this part. But slill. (2) -O2 In my DoCon programs, -O2 was always worse than -O: the code is about 1.3 times larger and 1.2 times slower. There are some particular points in my programs. For example, almost everywhere I set Integer rather than Int, I do not recall others, now. In never complained on (1) and (2) because did not recall of them and because they do not bite me in practice, so far. ----------------- Serge Mechveliani mechvel@botik.ru From mechvel at botik.ru Thu Oct 18 03:56:27 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Oct 18 03:54:32 2007 Subject: 6.8.1-candidate tested Message-ID: <20071018075627.GA2818@scico.botik.ru> Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, 3) the test runs 1.4 times faster, 4) the minimal space (2500 Kb) for the test running remains. This looks all right. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From simonpj at microsoft.com Thu Oct 18 05:07:08 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 18 05:05:15 2007 Subject: ANNOUNCE: GHC 6.8.1 Second Release Candidate In-Reply-To: <018a01c810d1$0e4632f0$40458351@cr3lt> References: <20071017131123.GA28173@matrix.chaos.earth.li> <018a01c810d1$0e4632f0$40458351@cr3lt> Message-ID: | - the list of outstanding issues for 6.8 branch is suspiciously long. has | this been reviewed in detail? Good point, Claus. Lots of people are using GHC for lots of things. This is a nice problem to have! But it does lead to lots of bug reports. We have limited resources, so we have to decide how best to spend them. In this case we have not reviewed the 6.8 list "in detail" because we thought it was more important to fix the ones that we knew were important. A major reason for Ian's announcement is that we'd like to give everyone an opportunity to say "this one is really important to me". We certainly might have missed ones that actually are important. We also started the "add yourself to the cc list" mechanism, to enable the community to say which bugs are important to them. | several of the tickets look more or less | fixed, and there seems to be nothing standing in the way for fixing | some more, such as this one: | http://hackage.haskell.org/trac/ghc/ticket/1226 We would absolutely love help from you or anyone else to verify that the ones that are more or less fixed are indeed fixed; and to fix ones for which there is nothing standing in the way. Simon From simonmarhaskell at gmail.com Thu Oct 18 06:33:52 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Oct 18 06:32:01 2007 Subject: 6.8.1-candidate tested In-Reply-To: <20071018075627.GA2818@scico.botik.ru> References: <20071018075627.GA2818@scico.botik.ru> Message-ID: <47173690.4000008@gmail.com> Serge D. Mechveliani wrote: > Dear GHC developers, > > I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on > Dumatel. > It looks all right > > (except the bug-candidate for -O which is common to all GHC versions > and which I recently reported > ). > > On DoCon, ghc-6.8.0.20071015 > 1) builds the project 2-3 times faster than ghc-6.6.1, > 2) its produced .a code is 1.6 times larger, I have noticed binary sizes increasing by around 20% on the nofib suite too. We've discovered one issue with some dictionaries not being inlined when we would expect them to, but there may be others. I'm investigating. Cheers, Simon From mechvel at botik.ru Thu Oct 18 06:41:49 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Oct 18 06:40:15 2007 Subject: 6.8.1-candidate tested In-Reply-To: <47173690.4000008@gmail.com> References: <20071018075627.GA2818@scico.botik.ru> <47173690.4000008@gmail.com> Message-ID: <20071018104149.GA5551@scico.botik.ru> On Thu, Oct 18, 2007 at 11:33:52AM +0100, Simon Marlow wrote: > Serge D. Mechveliani wrote: > >Dear GHC developers, > > > >I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on > >Dumatel. > >It looks all right > > > >(except the bug-candidate for -O which is common to all GHC versions > >and which I recently reported > >). > > > >On DoCon, ghc-6.8.0.20071015 > >1) builds the project 2-3 times faster than ghc-6.6.1, > >2) its produced .a code is 1.6 times larger, > > I have noticed binary sizes increasing by around 20% on the nofib suite > too. We've discovered one issue with some dictionaries not being inlined > when we would expect them to, but there may be others. I'm investigating. > All this you can easily reproduce in the public docon-2.10: build the library under -O, build demotest/Main under -Onot and see the timing of everything and the .a size. Then try to build demotest/Main under -O. And compare to 6.6.1. Regards, ----------- Mechveliani From p.k.f.holzenspies at utwente.nl Thu Oct 18 07:15:53 2007 From: p.k.f.holzenspies at utwente.nl (Philip =?utf-8?B?Sy5GLiBIw7ZsemVuc3BpZXM=?=) Date: Thu Oct 18 07:13:59 2007 Subject: Why only inference in type checking? Message-ID: <20071018111553.GA2138@ewi1043.ewi.utwente.nl> Dear All, A while ago, I had trouble understanding the coverage condition and I raised a question on this mailing list. Help was swift and adequate, especially the reference to the paper entitled "Understanding Functional Dependencies via Constraint Handling Rules" was very useful. However, having considered the problem of non-termination of the type checker, I can't help but wonder why the type checker is "inference only." From the paper mentioned above, consider the following example: class Mul a b c | a b -> c where (*) :: a -> b -> c type Vec b = [b] instance Mul a b c => Mul a (Vec b) (Vec c) where ... f b x y = if b then (*) x [y] else y For actual arguments of f, there is no issue whatsoever with decidability. The type checker in my brain uses unification, i.e. top-down. The type checker in GHC uses inference, i.e. bottom-up. Why inference potentially suffers from non-termination for this program, I understand. My question is this: Is there a reason why type checking in GHC is inference-only, as opposed to a meet-in-the-middle combination of unification and inference? Would the type checker use both unification and inference (let's say alternating evaluation of both), the number of programs for which termination can be guaranteed is considerably larger - if I'm not mistaken, but I may very well have gotten it wrong. Regards, Philip PS. I realize that for this dependent typing scenario is useless once Type Families are here. I can't wait for a GHC with TFs. I raise this question, simply to understand why inference was chosen exclusively. From waldmann at imn.htwk-leipzig.de Thu Oct 18 07:19:30 2007 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu Oct 18 07:17:35 2007 Subject: ghc --make-parallel ? Message-ID: <47174142.7080401@imn.htwk-leipzig.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can ghc execute compilations in parallel? (With GNU make, I'd say "make -j 2" but how to achieve this with "ghc --make" ?) Thanks - J. Waldmann. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF0FB3ZnXZuOVyMIRAv0LAKCu8Ub2Cbb9xGNlfVNhLAKdwe/vXQCfUG0l RokmawVrEibckG7QknybMkg= =eQQY -----END PGP SIGNATURE----- From bbr at informatik.uni-kiel.de Thu Oct 18 07:47:07 2007 From: bbr at informatik.uni-kiel.de (Bernd Brassel) Date: Thu Oct 18 07:47:16 2007 Subject: Prevent optimization from tempering with unsafePerformIO Message-ID: <471747BB.1060207@informatik.uni-kiel.de> Hello to all who have given me hints an suggestions about this topic whether directly by mail or over the mailing list. I do now have a much more concrete idea of how to optimize my programs. Thanks for your time! Bernd From simonmarhaskell at gmail.com Thu Oct 18 08:27:51 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Oct 18 08:26:01 2007 Subject: ghc --make-parallel ? In-Reply-To: <47174142.7080401@imn.htwk-leipzig.de> References: <47174142.7080401@imn.htwk-leipzig.de> Message-ID: <47175147.4010402@gmail.com> Johannes Waldmann wrote: > Can ghc execute compilations in parallel? > (With GNU make, I'd say "make -j 2" > but how to achieve this with "ghc --make" ?) Sorry, not at the moment. We implemented a hacky version of it for our Haskell Workshop '05 paper: http://haskell.org/~simonmar/bib/multiproc05_abstract.html but later concluded that GHC really needed some more substantial re-engineering to make it reliable. There's a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/910 Cheers, Simon From claus.reinke at talk21.com Thu Oct 18 09:50:59 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Oct 18 09:49:11 2007 Subject: ANNOUNCE: GHC 6.8.1 Second Release Candidate References: <20071017131123.GA28173@matrix.chaos.earth.li><018a01c810d1$0e4632f0$40458351@cr3lt> Message-ID: <022601c8118d$eb8f30f0$5a177ad5@cr3lt> >| - the list of outstanding issues for 6.8 branch is suspiciously long. has >| this been reviewed in detail? > >Good point, Claus. Lots of people are using GHC for lots of things. >This is a nice problem to have! But it does lead to lots of bug reports. >We have limited resources, so we have to decide how best to spend >them. In this case we have not reviewed the 6.8 list "in detail" because >we thought it was more important to fix the ones that we knew were >important. i tried to explain my concerns to Ian off-list, but i'll make another attempt here, adding some related points about the tracker that have been on my mind for a while now. sorry if that make this reply longer, but i think the points are important (i would think that, wouldn't i?-). as usual, please understand that i hope this criticism may help you to get more out of your efforts, which i appreciate as much as others do: - people submit bugreports because they hope something is done about them; ideally, that something would be a fix, but with limited resources, that isn't always possible - i understand; what should be possible, though, is to let everyone know where each ticket stands, what is going to happen when, and that it hasn't just been forgotten - your previous habit of going through all tickets when a release comes up, and either assigning them or moving their milestone, was reassuring - one might disagree with your decisions, but at least nothing was forgotten, and it was clear what happened; my main suggestion was _not_ to abandon that habit for this and future releases. - the longer tickets stay in the tracker, the more tickets there'll be, the more difficult it will be to find the "important" ones, and the more difficult it will be to ensure that things don't fall by the wayside (noone bothers to report things they do not find important); the number of tickets in the tracker is not just a function of users vs resources, it is also affected by the way workflows are organised, and the efficiency of the tracker in supporting such organisation if you try to go through all tickets even briefly, i hope you'll agree with the following: - the current tracking system is not set up efficiently: one cannot tell the state of play just by looking at a ticket, but has to delve into the comments instead; in brief, trac is still mostly tracking tickets, instead of tracking the state of work in a workflow. just from looking at a ticket (not its description/history), it should be clear what its status is, what the next action is (need not be fix/merge, but could be: getting a testcase, clarifying an issue, looking up some specs, consulting some expert, waiting for a buildbot donation, waiting for a volunteer, ..; anything that explains what is holding things up), who's responsible for that next action (might be the submitter, the assignee, or a third party), what the deadline for that next action is (so people can make plans and decisions), and what is going to happen afterwards (so that everyone can see the intended workflow). the current system tells me none of that, it only tells me at what milestone the ticket will next be reviewed, and you're about to abandon even that guarantee. - clearing mostly fixed tickets away completely saves time and effort, delaying them creates extra work and clogs up the tracker - having whole groups of tickets without any milestone, or with obsolete milestones, stongly suggests that the tracker has passed its limits of useability and needs to be looked into as a matter of urgency before things get worse >We also started the "add yourself to the cc list" mechanism, >to enable the community to say which bugs are important to >them. is there a query that lists tickets in priority order? also, each ticket should include its priority ranking and a text saying: "add yourself to the cc list if you want to raise this ticket". other suggestions for the tracker: adding more status/next action/deadline/actor fields would help, if trac supports that (could be simple free-form text fields, or selections), and adding an email interface, so that you can simply forward an email to the tracker if you know your todo list is already full, to get back an issue/ ticket number (a lot better than to tell the sender to go away and submit a ticket, btw; you could initialise the ticket with the email, then ask the sender to fill in the details; there could be bugs-ghc-head@ and bugs-ghc-release@). also, if you want to increase the use of the tracker for patches, there needs to be a document flow (submitter sends patch for review, assignee reviews and returns comments, submitter updates patch, submitter adds tests, assignee takes over patch, assignee validates/ applies to head, release maintainer takes over patch, etc), not just attachments to tickets. it needs to be obvious not only what files there are, but what files there should be, and who is doing what with them when. again, all of this should be in the formal part of the ticket, visible at a glance, not buried in the ticket history and discussion. >| several of the tickets look more or less >| fixed, and there seems to be nothing standing in the >| way for fixing some more, such as this one: >| http://hackage.haskell.org/trac/ghc/ticket/1226 > >We would absolutely love help from you or anyone else >to verify that the ones that are more or less fixed are indeed >fixed; and to fix ones for which there is nothing standing in >the way. please don't get me started on this!-) the reason i noticed that the tracking system is in a bad state is because i did contribute solutions, and recorded them in tickets, but nothing seems to happen with those tickets; or i report issues, they get assigned to milestones that then disappear (6.6.2) and nothing else happens (no action, not even a comment). i've also been trying to contribute three patches over the last two months, and they are still not in; the various, mostly non-technical delays, combined with the various non-problem-specific hurdles, sent me a clear message of "don't bother". in all this time, less than a week was spend on technical issues with the patches themselves, the rest was extraneous. we're now getting to discuss final technical details at last, and i intend to see these patches through, but i'll think more than twice before sending any new ones. then i switched to submitting code without patch, in the hope that this would help to resolve tickets that are important to me, such as #1226; as far as i can tell, that ticket could then have been fixed in 5-10 minutes, but nothing happened, and the "6.8 branch" is very unspecific about when anything will. i also don't think that the ticket reflects the implementation status (hasn't the windows issue reported there been fixed yet?). i hope this helps, and thanks again for your efforts, claus From simonpj at microsoft.com Thu Oct 18 10:13:48 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 18 10:11:55 2007 Subject: Why only inference in type checking? In-Reply-To: <20071018111553.GA2138@ewi1043.ewi.utwente.nl> References: <20071018111553.GA2138@ewi1043.ewi.utwente.nl> Message-ID: | For actual arguments of f, there is no issue whatsoever with | decidability. The type checker in my brain uses unification, i.e. | top-down. The type checker in GHC uses inference, i.e. bottom-up. Why | inference potentially suffers from non-termination for this program, I | understand. Actually GHC's type check uses checking when it knows the types, and inference only when it doesn't. | My question is this: Is there a reason why type checking in GHC is | inference-only, as opposed to a meet-in-the-middle combination of | unification and inference? It exactly does meet-in-the-middle. Maybe you can elaborate your reasoning? In any case, the restrictions on fundeps are needed for checking too. I believe. Simon From pocm at soton.ac.uk Thu Oct 18 12:47:35 2007 From: pocm at soton.ac.uk (Paulo J. Matos) Date: Thu Oct 18 12:45:39 2007 Subject: Command Line Arguments Message-ID: <11b141710710180947q508deb26te06a10b20163523e@mail.gmail.com> As an Haskell beginner, and considering this may be compiler dependent, I shall ask it on this list. How can I access command line arguments from my main function in my Main module? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK From ndmitchell at gmail.com Thu Oct 18 13:07:58 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Oct 18 13:06:04 2007 Subject: Command Line Arguments In-Reply-To: <11b141710710180947q508deb26te06a10b20163523e@mail.gmail.com> References: <11b141710710180947q508deb26te06a10b20163523e@mail.gmail.com> Message-ID: <404396ef0710181007s3ffbbb63sf85b5a943f97485@mail.gmail.com> Hi > As an Haskell beginner, and considering this may be compiler > dependent, I shall ask it on this list. It's standard across all implementations. > How can I access command line arguments from my main function in my Main module? import System.Environment main = do args <- getArgs print args You can also do in GHCi and Hugs: :main test arguments To test your code with argument values. Thanks Neil From pocm at soton.ac.uk Thu Oct 18 13:37:08 2007 From: pocm at soton.ac.uk (Paulo J. Matos) Date: Thu Oct 18 13:35:14 2007 Subject: Command Line Arguments In-Reply-To: <404396ef0710181007s3ffbbb63sf85b5a943f97485@mail.gmail.com> References: <11b141710710180947q508deb26te06a10b20163523e@mail.gmail.com> <404396ef0710181007s3ffbbb63sf85b5a943f97485@mail.gmail.com> Message-ID: <11b141710710181037s3d57385cw2548fb55cb394a66@mail.gmail.com> On 18/10/2007, Neil Mitchell wrote: > Hi > > > As an Haskell beginner, and considering this may be compiler > > dependent, I shall ask it on this list. > > It's standard across all implementations. > So that's part of the Haskell98 standard? Nice! So, is it usual for compilers to implement extensions to the standard? If yes, where can I find the documentation for GHC extensions? > > How can I access command line arguments from my wmain function in my Main module? > > import System.Environment > > main = do > args <- getArgs > print args > Thank you! > You can also do in GHCi and Hugs: > > :main test arguments > > To test your code with argument values. > > Thanks > > Neil > > > -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK From ndmitchell at gmail.com Thu Oct 18 13:46:33 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Oct 18 13:44:38 2007 Subject: Command Line Arguments In-Reply-To: <11b141710710181037s3d57385cw2548fb55cb394a66@mail.gmail.com> References: <11b141710710180947q508deb26te06a10b20163523e@mail.gmail.com> <404396ef0710181007s3ffbbb63sf85b5a943f97485@mail.gmail.com> <11b141710710181037s3d57385cw2548fb55cb394a66@mail.gmail.com> Message-ID: <404396ef0710181046n157551a5j27e908bd174a3b7f@mail.gmail.com> Hi > So that's part of the Haskell98 standard? In the Haskell98 standard it can be imported from System, rather than System.Environment. Nowadays all compilers can use either. > Nice! So, is it usual for compilers to implement extensions to the > standard? If yes, where can I find the documentation for GHC > extensions? Different compilers have different extensions. Yhc has very few, Hugs has a couple, GHC has loads. They are documented in the GHC manual. Thanks Neil From isaacdupree at charter.net Thu Oct 18 15:26:36 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Thu Oct 18 15:26:12 2007 Subject: ANNOUNCE: GHC 6.8.1 Second Release Candidate In-Reply-To: <022601c8118d$eb8f30f0$5a177ad5@cr3lt> References: <20071017131123.GA28173@matrix.chaos.earth.li><018a01c810d1$0e4632f0$40458351@cr3lt> <022601c8118d$eb8f30f0$5a177ad5@cr3lt> Message-ID: <4717B36C.6070401@charter.net> Claus Reinke wrote: > - people submit bugreports because they hope something is done > about them often. Sometimes I submit a bugreport to make sure the issue isn't completely forgotten, not because it's an important issue to me. (not really disagreeing, just saying) Isaac From rturk at science.uva.nl Thu Oct 18 18:14:31 2007 From: rturk at science.uva.nl (Remi Turk) Date: Thu Oct 18 18:10:16 2007 Subject: type families not advertised for 6.8 In-Reply-To: References: <200710171857.02098.g9ks157k@acme.softbase.org> <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> Message-ID: <20071018221431.GA3442@krikkit.lan> On Thu, Oct 18, 2007 at 02:58:21AM +0100, Simon Peyton-Jones wrote: > | > Absolutely not; quite the reverse. It means that some of the *code* for > | type functions happens to be in the 6.8 release --- but that code has bugs. > | It's only in 6.8 for our convenience (to avoid too great a divergence between > | the HEAD and 6.8), but we do not plan to *support* type functions in 6.8. > | Doing that would delay 6.8 by 3 months. > | > | Do you make any difference between associated type synonyms and type > | functions in this respect? > > No difference: both are in the 6.8 code base, but we won't > support them there. Both are in the HEAD, and we will support > them there. What does this imply for 6.8 support for FD's, as they now use the same type-coercions? Groeten, Remi From duncan.coutts at worc.ox.ac.uk Thu Oct 18 19:18:16 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 18 19:13:28 2007 Subject: ghc --make-parallel ? In-Reply-To: <47174142.7080401@imn.htwk-leipzig.de> References: <47174142.7080401@imn.htwk-leipzig.de> Message-ID: <1192749496.8926.44.camel@localhost> On Thu, 2007-10-18 at 13:19 +0200, Johannes Waldmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Can ghc execute compilations in parallel? > (With GNU make, I'd say "make -j 2" > but how to achieve this with "ghc --make" ?) We're also going to try and solve this in Cabal by having Cabal do the module dependency analysis and then call ghc (and pre-processors) in single shot mode and in parallel. Duncan From simonpj at microsoft.com Fri Oct 19 03:25:22 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 19 03:23:27 2007 Subject: type families not advertised for 6.8 In-Reply-To: <20071018221431.GA3442@krikkit.lan> References: <200710171857.02098.g9ks157k@acme.softbase.org> <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> <20071018221431.GA3442@krikkit.lan> Message-ID: | What does this imply for 6.8 support for FD's, as they now use | the same type-coercions? Actually FDs do not use type coercions, in GHC at least. As Mark originally described them, FDs guide inference; and in particular, they give rise to some unifications that would not otherwise occur. In terms of the intermediate language, that means there is no "evidence" associated with a FD; it's just the type checker's business. That means that various potentially-useful things can't be expressed, notably when FDs are combined with existentials or GADTs, that involve *local* equalities, which were beyond the scope of Marks's original paper. As the recent thread about FDs shows, FDs are quite tricky, at least if one goes beyond the well-behaved definition that Mark originally gave. (And FDs are much more useful if you go beyond.) Our current plan is to regard FDs as syntactic sugar for indexed type families. We think this can be done -- see our IFL workshop paper http://research.microsoft.com/%7Esimonpj/papers/assoc-types No plans to remove them, however. After all, we do not have much practical experience with indexed type families yet, so it's too early to draw many judgements about type families vs FDs. I recommend Iavor's thesis incidentally, which has an interesting chapter about FDs, including some elegant (but I think unpublished) syntactic sugar that makes a FD look more like a function. I don't think it's online, but I'm sure he can rectify that. Simon From p.k.f.holzenspies at utwente.nl Fri Oct 19 04:37:56 2007 From: p.k.f.holzenspies at utwente.nl (Philip =?utf-8?B?Sy5GLiBIw7ZsemVuc3BpZXM=?=) Date: Fri Oct 19 04:35:59 2007 Subject: Why only inference in type checking? In-Reply-To: References: <20071018111553.GA2138@ewi1043.ewi.utwente.nl> Message-ID: <20071019083756.GA7907@ewi1043.ewi.utwente.nl> Dear Simon, You mentioned that GHC uses 'checking' when it knows the types. How this relates to 'unification', I don't know. It might very well be the same. Hopefully, the following example sheds a bit more light on what I mean (carefully nicked from Uktaad B'mal's "Beginning Faking It"). Examples are many, including in the "Understanding FDs via CHRs" paper. -- Start example To define 'vectors,' we need to code the length of a list in a type. With the zero/successor notation for naturals, we can do this is data constructors without term-level constructors: data Z data S x Vector concatenation requires addition of these numerals. In Prolog terms: Add(zero, X, X). Add(s X, Y, s Z) :- Add X Y Z We can translate this to a type class as class Add a b c | a b -> c instance Add Z x x instance Add x y z => Add (S x) y (S z) -- End example Because of your paper I understand why the coverage condition is in place and why it fails for the last of these instance declarations. GHC will allow me to do this by saying allow-undecidable-instances. As you state in the paper, the three FD-conditions of Coverage, Consistency and Bound Variable are sufficient, but not (always) necessary. I see why the example above causes considerable problems for inference, but if I read these instance declarations as Horn clauses, I see no problem at all in checking any actual occurrence in a program, i.e. if I write a concatenation function for vectors that uses this class as a property of vectors, I don't see where a type checker, using Prolog-like unification, runs into difficulties. What I'm probably asking (it's hard to tell, even for me, sometimes), is whether there is something between a type checker that is guaranteed to terminate and throwing all guarantees with regards to decidability right out the window. Again, I might be completely mistaken about how GHC does this. In that case I would like to find out where I make a wrongful assumption. Regards, Philip From g9ks157k at acme.softbase.org Fri Oct 19 04:50:45 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Oct 19 04:49:26 2007 Subject: type families not advertised for 6.8 In-Reply-To: References: <200710171857.02098.g9ks157k@acme.softbase.org> <20071018221431.GA3442@krikkit.lan> Message-ID: <200710191050.46074.g9ks157k@acme.softbase.org> Am Freitag, 19. Oktober 2007 09:25 schrieb Simon Peyton-Jones: > [?] > Our current plan is to regard FDs as syntactic sugar for indexed type > families. We think this can be done -- see our IFL workshop paper > http://research.microsoft.com/%7Esimonpj/papers/assoc-types I doubt this can be done in all cases. Take the following code which is more or less from HList: {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, OverlappingInstances, UndecidableInstances, TypeFamilies, EmptyDataDecls #-} data False data True class TypeEq t1 t2 b | t1 t2 -> b where typeEq :: t1 -> t2 -> b instance TypeEq t t True where typeEq = undefined instance (b ~ False) => TypeEq t1 t2 b where typeEq = undefined If you convert this code according to the above-cited paper to use type families instead of functional dependencies, you run into several problems. First, type families don?t allow overlapping with conflicting results. Interestingly, the compiler doesn?t complain about the overlapping but about two other things. In the first instance declaration you have something like type TypeEqTF t t = True which results in the error ?Conflicting definitions for `t'?. In addition, the second instance declaration which includes something like type TypeEqTF t1 t2 = b causes the error ?Not in scope: type variable `b'?. This latter problem can be circumvented by writing type TypeEqTF t1 t2 = False but it shows that the automatic translation doesn?t work here. In fact, after thinking and experimenting I came to the conclusion that it?s probably just not possible to define a type function TypeEqTF t1 t2 which for *all* types t1 and t2 yields True or False, depending on whether t1 and t2 are equal or not. > [?] > Simon Best wishes, Wolfgang From simonpj at microsoft.com Fri Oct 19 05:32:36 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 19 05:29:42 2007 Subject: type families not advertised for 6.8 In-Reply-To: <200710191050.46074.g9ks157k@acme.softbase.org> References: <200710171857.02098.g9ks157k@acme.softbase.org> <20071018221431.GA3442@krikkit.lan> <200710191050.46074.g9ks157k@acme.softbase.org> Message-ID: Wolfgang Yes, that?s interesting. As you know, you have to turn off overlap checks and allow non-terminating instances to make this HList stuff work. There's nothing to stop us doing the same for type functions, although we have not yet done so. (Too busy making the basic thing work.) For example, | In fact, after thinking and experimenting I came to the conclusion that it?s | probably just not possible to define a type function TypeEqTF t1 t2 which for | *all* types t1 and t2 yields True or False, depending on whether t1 and t2 | are equal or not. That's a nice crisp example. It's a pure function, at the level of types, so you'd think it should be definable. And I don't think there is any reason we couldn't do so (in due course). For example, overlap is fine, so long as when we *use* an equation there is only one that applies, so that there is a unique answer. Similarly I think we could reasonably allow type instance F t t = ... You are certainly right that type functions today don't do all that FDs (as implemented in GHC at least) do. It'd be quite useful to identify just what extra features are needed in the type-function world would be needed to do HList kind of stuff. (Oh, it's just possible that HList might be architected differently if type functions were available.) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Wolfgang Jeltsch | Sent: 19 October 2007 09:51 | To: glasgow-haskell-users@haskell.org | Subject: Re: type families not advertised for 6.8 | | Am Freitag, 19. Oktober 2007 09:25 schrieb Simon Peyton-Jones: | > [?] | | > Our current plan is to regard FDs as syntactic sugar for indexed type | > families. We think this can be done -- see our IFL workshop paper | > http://research.microsoft.com/%7Esimonpj/papers/assoc-types | | I doubt this can be done in all cases. Take the following code which is more | or less from HList: | | {-# LANGUAGE | MultiParamTypeClasses, | FunctionalDependencies, | FlexibleInstances, | OverlappingInstances, | UndecidableInstances, | TypeFamilies, | EmptyDataDecls | #-} | | data False | | data True | | class TypeEq t1 t2 b | t1 t2 -> b where | typeEq :: t1 -> t2 -> b | | instance TypeEq t t True where | typeEq = undefined | | instance (b ~ False) => TypeEq t1 t2 b where | typeEq = undefined | | If you convert this code according to the above-cited paper to use type | families instead of functional dependencies, you run into several problems. | | First, type families don?t allow overlapping with conflicting results. | Interestingly, the compiler doesn?t complain about the overlapping but about | two other things. In the first instance declaration you have something like | | type TypeEqTF t t = True | | which results in the error ?Conflicting definitions for `t'?. In addition, | the second instance declaration which includes something like | | type TypeEqTF t1 t2 = b | | causes the error ?Not in scope: type variable `b'?. This latter problem can | be circumvented by writing | | type TypeEqTF t1 t2 = False | | but it shows that the automatic translation doesn?t work here. | | In fact, after thinking and experimenting I came to the conclusion that it?s | probably just not possible to define a type function TypeEqTF t1 t2 which for | *all* types t1 and t2 yields True or False, depending on whether t1 and t2 | are equal or not. | | > [?] | | > Simon | | Best wishes, | Wolfgang | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From g9ks157k at acme.softbase.org Fri Oct 19 07:03:22 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Oct 19 07:01:49 2007 Subject: type families not advertised for 6.8 In-Reply-To: References: <200710171857.02098.g9ks157k@acme.softbase.org> <200710191050.46074.g9ks157k@acme.softbase.org> Message-ID: <200710191303.22349.g9ks157k@acme.softbase.org> Am Freitag, 19. Oktober 2007 11:32 schrieben Sie: > [?] > | In fact, after thinking and experimenting I came to the conclusion that > | it?s probably just not possible to define a type function TypeEqTF t1 t2 > | which for *all* types t1 and t2 yields True or False, depending on > | whether t1 and t2 are equal or not. > > That's a nice crisp example. It's a pure function, at the level of types, > so you'd think it should be definable. And I don't think there is any > reason we couldn't do so (in due course). For example, overlap is fine, > so long as when we *use* an equation there is only one that applies, so > that there is a unique answer. But the problem in the HList example is that two equations apply where the most specific one should be taken. > [?] > (Oh, it's just possible that HList might be architected differently if type > functions were available.) Yes, but as soon as you start to implement records where field names are types, you have to have a compile-time type equality check since you need it for lookup and for making sure that the same field name doesn?t occur twice in one record. So even if HList would be architectured rather differently, it would probably still need an equality test. > Simon Best wishes, Wolfgang From simonpj at microsoft.com Fri Oct 19 07:44:37 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 19 07:41:44 2007 Subject: type families not advertised for 6.8 In-Reply-To: <200710191303.22349.g9ks157k@acme.softbase.org> References: <200710171857.02098.g9ks157k@acme.softbase.org> <200710191050.46074.g9ks157k@acme.softbase.org> <200710191303.22349.g9ks157k@acme.softbase.org> Message-ID: | But the problem in the HList example is that two equations apply where the | most specific one should be taken. There is no difficulty in principle with this. You just need to state (and implement) the rule that the most specific equation applies. That is, there's no reason in principle you should not be able to write type instance Eq t t = True type instance Eq a b = False BUT, we need to take care here. There is one way in which indexed type family instances differ in a fundamental way from type-class instances (and hence FDs). Suppose we have module M where class C a where { foo :: ... } instance C [a] where ... Now suppose you import this into module X module X where import M instance C [Int] where ... Now, with type classes it's sort-of-OK that inside M we'll use one instance decl for (C [Int]), but a different one inside X. OK, so the two implementations of method foo will be different, but the program won't crash. Things are different with type families. Suppose we have module M where type family F :: * -> * type instance F [a] = a module X where import M type instance F [Int] = Bool Then you'll get a *seg fault* if you use the F [a] instance in one place, and the F [Int] instance in another place, when resolving a constraint involving F [Int]! (Because Bool /= Int.) That is why the current impl strictly rules out overlap for type families. Our proposed solution is that you can only use overlapping type-family instances for "closed" type families; here "closed" means that you can't add "more" instance later. Something like this: type family Eq :: * -> * -> * where Eq t t = True Eq t1 t2 = False (The 'where' means it's a closed family.) Which is fine for the application you mention. Of course none of this is implemented! Simon From g9ks157k at acme.softbase.org Fri Oct 19 09:14:13 2007 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Oct 19 09:12:23 2007 Subject: type families not advertised for 6.8 In-Reply-To: References: <200710171857.02098.g9ks157k@acme.softbase.org> <200710191303.22349.g9ks157k@acme.softbase.org> Message-ID: <200710191514.13835.g9ks157k@acme.softbase.org> Am Freitag, 19. Oktober 2007 13:44 schrieben Sie: > [?] > Of course none of this is implemented! But it all sounds very cool. I would like it. :-) > Simon Best wishes, Wolfgang From simonpj at microsoft.com Fri Oct 19 10:50:22 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 19 10:47:28 2007 Subject: type families not advertised for 6.8 In-Reply-To: <200710191514.13835.g9ks157k@acme.softbase.org> References: <200710171857.02098.g9ks157k@acme.softbase.org> <200710191303.22349.g9ks157k@acme.softbase.org> <200710191514.13835.g9ks157k@acme.softbase.org> Message-ID: | | > Of course none of this is implemented! | | But it all sounds very cool. I would like it. :-) ...and you shall have it :-) Simon From bulat.ziganshin at gmail.com Fri Oct 19 14:33:03 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Oct 19 14:54:00 2007 Subject: GHC benchmarks In-Reply-To: <4713465A.5090205@gmail.com> References: <87zlyqjaiz.fsf@nmd9999.imr.no> <470E2689.8040300@gmail.com> <87lka83e0j.fsf@nmd9999.imr.no> <4713465A.5090205@gmail.com> Message-ID: <234682316.20071019223303@gmail.com> Hello Simon, Monday, October 15, 2007, 2:52:10 PM, you wrote: > Right - GC time doubled, which is what we'd expect to see when the resident > data size doubles. The decrease in MUT time is probably due to the extra > registers available, but MUT time would also be affected by the increase in > data size, because the cache hit rate should be lower. On the whole, I > think these results are to be expected. > There isn't much we can do to improve things in the short term, I'm afraid. usimng just "+RTS -A10m" may help -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From mechvel at botik.ru Sat Oct 20 13:11:08 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Sat Oct 20 13:08:56 2007 Subject: -O in 6.8.1-candidate In-Reply-To: <1192890304.9251.80.camel@localhost> References: <20071017184913.GA25033@scico.botik.ru> <20071017185123.GD8916@scytale.galois.com> <1192657696.8926.22.camel@localhost> <20071018070249.GA1706@scico.botik.ru> <1192753527.9251.1.camel@localhost> <20071019073404.GA23088@scico.botik.ru> <1192785244.9251.19.camel@localhost> <4718B71C.2040908@charter.net> <1192890304.9251.80.camel@localhost> Message-ID: <20071020171108.GA3610@scico.botik.ru> On Sat, Oct 20, 2007 at 03:25:04PM +0100, Duncan Coutts wrote: > On Fri, 2007-10-19 at 10:54 -0300, Isaac Dupree wrote: > > > How can user who does not modify Cabal file choose between all three of > > -O0, -O and -O2? > > They cannot. Cabal currently only support a binary notion of > optimisations. So it's either -O0 or -O. > As I understand, the Cabal developers claim that a user of an applied package p does not need to change anything in the file p.cabal. But there is a contradition here. For example, a user may need to build p via p.cabal under GHC and once under -Onot and next time under -O2. Suppose also that once the user needs to build p under -prof -auto-all and next time -- under -prof only. How can one do all this without intruding into p.cabal ? Personally, I would like better if the default for Cabal does not set any GHC options, and a user to be invited to edit the field `ghc-options:' in the .cabal file. This way, it looks simpler and less confusive. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From duncan.coutts at worc.ox.ac.uk Sat Oct 20 13:38:44 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Oct 20 13:33:50 2007 Subject: -O in 6.8.1-candidate In-Reply-To: <20071020171108.GA3610@scico.botik.ru> References: <20071017184913.GA25033@scico.botik.ru> <20071017185123.GD8916@scytale.galois.com> <1192657696.8926.22.camel@localhost> <20071018070249.GA1706@scico.botik.ru> <1192753527.9251.1.camel@localhost> <20071019073404.GA23088@scico.botik.ru> <1192785244.9251.19.camel@localhost> <4718B71C.2040908@charter.net> <1192890304.9251.80.camel@localhost> <20071020171108.GA3610@scico.botik.ru> Message-ID: <1192901925.9251.108.camel@localhost> On Sat, 2007-10-20 at 21:11 +0400, Serge D. Mechveliani wrote: > On Sat, Oct 20, 2007 at 03:25:04PM +0100, Duncan Coutts wrote: > > On Fri, 2007-10-19 at 10:54 -0300, Isaac Dupree wrote: > > > > > How can user who does not modify Cabal file choose between all three of > > > -O0, -O and -O2? > > > > They cannot. Cabal currently only support a binary notion of > > optimisations. So it's either -O0 or -O. > > > > As I understand, the Cabal developers claim that a user of an applied > package p does not need to change anything in the file p.cabal. That is the aim, yes. > But there is a contradition here. > For example, a user may need to build p via p.cabal under GHC and > once under -Onot and next time under -O2. Suppose also that once the > user needs to build p under -prof -auto-all and next time -- under > -prof only. How can one do all this without intruding into p.cabal ? We don't claim that every possible ghc feature is exposed conveniently via Cabal. (If it were, there would be no point to having Cabal at all) So Cabal provides a way for users to choose between optimising or not, and building for profiling or not. The distinction between -O and -O2, and the distinction between -prof and -prof -auto-all is not something that Cabal exposes in a Haskell-implementation-independent way. If this is something that is vital for your users then there is the more general (but less convenient) Cabal configurations system. You can have flags which can be set by the user and you can define how the affect how your package is built. For example: flag optimise-more description: ... library ... if flag(optimise-more) ghc-options: -O2 jhc-options: ... Then you would tell your users to use an extra flag at configuration time: runghc Setup.hs configure -f optimise-more > Personally, I would like better if the default for Cabal does not set > any GHC options, and a user to be invited to edit the field > `ghc-options:' in the .cabal file. This way, it looks simpler and > less confusive. The problem with that is that it does not help make their packages portable between different Haskell implementations and it requires that all users know what the short cryptic ghc command line options mean. Editing a .cabal file is also something that does not make packaging convenient. For example how is a user of a rpm package, or someone using cabal-install supposed to specify these configuration options if they have to edit the .cabal file by hand? Duncan From rturk at science.uva.nl Sat Oct 20 16:25:20 2007 From: rturk at science.uva.nl (Remi Turk) Date: Sat Oct 20 16:20:54 2007 Subject: type families not advertised for 6.8 In-Reply-To: References: <200710171857.02098.g9ks157k@acme.softbase.org> <953e0d250710171324r268b1af2l92970bcee2c99ddd@mail.gmail.com> <20071018221431.GA3442@krikkit.lan> Message-ID