RE: Implicit 'forall' in data declarations
| On a related note, these are also apparently allowed (in 6.10.4): | f :: forall a. (Eq a = a - a) - a - a |-- the Eq context prevents the function from ever being called. That's not true. E.g. f ((==) True) True works fine. |g :: forall a. Ord a = (Eq a = a - a) - a - a |-- the Eq context is effectively ignored That's a bit more true, because Ord a implies Eq a, but still not really. It still says that you must pass evidence for equality to g's argument. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Implicit 'forall' in data declarations
On Mon, Oct 25, 2010 at 3:16 AM, Simon Peyton-Jones simo...@microsoft.com wrote: | On a related note, these are also apparently allowed (in 6.10.4): | f :: forall a. (Eq a = a - a) - a - a | -- the Eq context prevents the function from ever being called. That's not true. E.g. f ((==) True) True works fine. What I meant is that f cannot call its argument. That is, f :: forall a. (Eq a = a - a) - a - a f g x = g x is ill-typed. | g :: forall a. Ord a = (Eq a = a - a) - a - a | -- the Eq context is effectively ignored That's a bit more true, because Ord a implies Eq a, but still not really. It still says that you must pass evidence for equality to g's argument. Is that different from forall a. Ord a = (a - a) - a - a? -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: context-stack GHC 7.0.1 Release Candidate 1
Implementing fundeps in the new solver has proved more complicated than we thought at first. I’m not aware of any obvious “oh, this is going to perform really badly” parts. My gut feel is that the inference engine will work better using type functions, but I can’t put any real evidence behind that claim. If you have a low-cost way to experiment we’d love to hear what you find. But don’t burn a month converting in case it makes no difference! Simon From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Corey O'Connor Sent: 22 October 2010 19:50 To: Simon Peyton-Jones Cc: glasgow-haskell-users@haskell.org Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 I was running into a similar issue and haven't noticed a dramatic improvement with the latest changes. The number of ticks taken to compile are approximately the same before and after the latest patch. However the system still compiles just fine with a context stack of 200. Which is OK by me. The system I'm working with uses functional dependencies and type families w/ type equalities. Could I improve the performance of my system by replacing the functional dependencies with type families type equalities? The part of the system that uses functional dependencies is monad-param: http://hackage.haskell.org/package/monad-param The other part of the system I can't release the source to yet. :-\ I know, not very useful. -Corey O'Connor coreyocon...@gmail.commailto:coreyocon...@gmail.com http://www.coreyoconnor.com On Tue, Oct 19, 2010 at 8:57 AM, Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: Christian Dimitrios and I (mainly D) have fixed this. Your system compiles nicely now. Can you try again with the HEAD? Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: context-stack GHC 7.0.1 Release Candidate 1
Am 19.10.2010 17:57, schrieb Simon Peyton-Jones: Christian Dimitrios and I (mainly D) have fixed this. Your system compiles nicely now. Can you try again with the HEAD? I've just checked with http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101024-x86_64-unknown-linux.tar.bz2 and hets compiles fine after setting -fcontext-stack=100. (I did not try smaller values yet.) Thanks a lot Christian Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Christian Maeder | Sent: 12 October 2010 12:47 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | | Am 08.10.2010 18:52, schrieb Simon Peyton-Jones: | Christian | | We've committed a wave of patches that should substantially improve the | typechecker. Could you try with the current HEAD? | | I've tried with | http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101010-x86_64-unknown- | linux.tar.bz2 | | and it became worse. With -fcontext-stack=200 | | [368 of 519] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | Logic/Comorphism.o ) | | did not go through within 109 minutes: | | PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND | | 27743 maeder20 0 316m 280m 17m R 100 1.7 109:27.22 ghc | | | Does this version contain the patches? | | (I'm currently compiling the HEAD, unless you tell me, that it won't help) | | Please don't release a compiler that can no longer compile our sources. | | Cheers Christian | | (Or you can wait for the next release candidate, end next week; but sooner is | better.) | | Simon | | | -Original Message- | | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | | users-boun...@haskell.org] On Behalf Of Christian Maeder | | Sent: 27 September 2010 15:32 | | Cc: glasgow-haskell-users@haskell.org | | Subject: Re: context-stack GHC 7.0.1 Release Candidate 1 | | | | Am 27.09.2010 15:12, schrieb Christian Maeder: | | I wasn't able to compile yet. After 4 minutes it failed with: | | | |Context reduction stack overflow; size = 46 | | | | and I'm increasing the context-stack further. | | | | It goes through with -fcontext-stack=100, but the compilation time is | | unacceptable. 55 minutes for the following two files on x86_64: | | | | [381 of 536] Compiling Logic.Comorphism ( Logic/Comorphism.hs, | | Logic/Comorphism.o ) | | [382 of 536] Compiling Logic.Modification ( Logic/Modification.hs, | | Logic/Modification.o ) | | | | And the second one isn't finished yet. | | | | C. | | | | Maybe this is related to: | | http://hackage.haskell.org/trac/ghc/ticket/816 | | | | (ghc-6.10.x or ghc-6.12.x have no such problems.) | | | | Cheers Christian | | ___ | | Glasgow-haskell-users mailing list | | Glasgow-haskell-users@haskell.org | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc7 typing problem
Again thanks, it works with ghc 7.1.20101024 C. Am 18.10.2010 18:16, schrieb Simon Peyton-Jones: Thanks. We knew about this -- in flight changes happening now -- but I've added it as a new regression test even so. Simon | -Original Message- | From: Christian Maeder [mailto:christian.mae...@dfki.de] | Sent: 15 October 2010 17:53 | To: GHC Users Mailing List | Cc: Simon Peyton-Jones | Subject: ghc7 typing problem | | Hi, | | I've looked at: | http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 | | but still have a problem with the attached program that fails with: | | GHCi, version 7.1.20101010: http://www.haskell.org/ghc/ :? for help Loading package | ghc-prim ... linking ... done. | Loading package integer-gmp ... linking ... done. | Loading package base ... linking ... done. | Loading package ffi-1.0 ... linking ... done. | [1 of 1] Compiling Main ( HasKey.hs, interpreted ) | | HasKey.hs:17:10: | Couldn't match type `key' with `key1' | because this skolem type variable would escape: `key1' | This skolem is bound by the instance declaration | In the instance declaration for `Ord (Keyed x)' | | at the final instance for Ord. | | The original code comes from | http://hackage.haskell.org/packages/archive/uni-util/2.2.0.0/doc/html/Util- | VariableSet.html | | Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Implicit 'forall' in data declarations
| | On a related note, these are also apparently allowed (in 6.10.4): | | f :: forall a. (Eq a = a - a) - a - a | | -- the Eq context prevents the function from ever being called. | | That's not true. E.g. | f ((==) True) True | works fine. | | What I meant is that f cannot call its argument. Oh now I see. Yes, that's true. But it could be hard to work out: f :: forall a. (C a, D a) = (E [a] = a - a) - Int Can 'f' call its argument? Well, it depends if you can deduce E [a] from (C a, D a). And if this was a local type signature there might be other constraints in scope. Anyway, it's certainly true that some types are more useful than others (e.g. (forall a. Int - a) must be the constant bottom function), but I don't think it's fruitful to try to exclude them *as types*. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
