RE: Should exhaustiveness testing be on by default?
No, the shortcomings are not documented I'm afraid. It's a squishy question because when you add guards and view patterns it's undecidable whether patterns overlap or are exhaustive. Still, GHC's current implementation is poor. It's a well-contained project that is awaiting a competent implementor. see http://hackage.haskell.org/trac/ghc/wiki/ProjectSuggestions Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Robert Greayer | Sent: 19 May 2009 04:00 | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Should exhaustiveness testing be on by default? | | On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey n...@eecs.harvard.edu wrote: | P.S. The exhaustiveness checker does need improvement... | | Is it documented somewhere what deficiencies the exhaustiveness | checker has (where it can report problems that don't exist or fails to | report problems that do...), and which deficiencies can't be resolved? | | | Rob | ___ | 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: Should exhaustiveness testing be on by default?
On 19/05/2009 08:37, Simon Peyton-Jones wrote: No, the shortcomings are not documented I'm afraid. It's a squishy question because when you add guards and view patterns it's undecidable whether patterns overlap or are exhaustive. There are various open bugs regarding exhaustiveness/incompleteness though. Start here: http://hackage.haskell.org/trac/ghc/ticket/595 and follow the links in the comments. Also http://hackage.haskell.org/trac/ghc/ticket/2395 for view patterns. Cheers, Simon Still, GHC's current implementation is poor. It's a well-contained project that is awaiting a competent implementor. see http://hackage.haskell.org/trac/ghc/wiki/ProjectSuggestions Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Robert Greayer | Sent: 19 May 2009 04:00 | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Should exhaustiveness testing be on by default? | | On Mon, May 18, 2009 at 4:00 PM, Norman Ramseyn...@eecs.harvard.edu wrote: | P.S. The exhaustiveness checker does need improvement... | | Is it documented somewhere what deficiencies the exhaustiveness | checker has (where it can report problems that don't exist or fails to | report problems that do...), and which deficiencies can't be resolved? | | | Rob | ___ | 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: Should exhaustiveness testing be on by default?
... exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds... Or even people from typed backgrounds. I worship at the altar of exhaustiveness checking. Do you really want exhaustiveness, or is what you actually want safety? With -fwarn-incomplete-patterns: test1 = head [] test2 = x where (x:xs) = [] test3 = (\(x:xs) - 1) [] test4 = f [] where f [] = 1 GHC reports that test4 has incomplete patterns, but the others don't. However, test4 is safe, but the others aren't. Exhaustiveness is a poor approximation of safety. GHC's exhaustiveness checker is a poor approximation of exhaustiveness. 2 is a poor approximation of pi :-) Using Catch, it reports that test1..3 were faulty, but test4 is safe. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should exhaustiveness testing be on by default?
Excellent, is there a -fuse-catch flag for ghc? :) On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell ndmitch...@gmail.com wrote: ... exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds... Or even people from typed backgrounds. I worship at the altar of exhaustiveness checking. Do you really want exhaustiveness, or is what you actually want safety? With -fwarn-incomplete-patterns: test1 = head [] test2 = x where (x:xs) = [] test3 = (\(x:xs) - 1) [] test4 = f [] where f [] = 1 GHC reports that test4 has incomplete patterns, but the others don't. However, test4 is safe, but the others aren't. Exhaustiveness is a poor approximation of safety. GHC's exhaustiveness checker is a poor approximation of exhaustiveness. 2 is a poor approximation of pi :-) Using Catch, it reports that test1..3 were faulty, but test4 is safe. Thanks Neil ___ 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: Should exhaustiveness testing be on by default?
Excellent, is there a -fuse-catch flag for ghc? :) No, but there is for Yhc. If you write to the Haskell standard (minus a little bit), don't like libraries and can get Yhc to compile (good luck!) then it's just a few command lines away. If GHC (or GHC + some scripts) could produce a single Core file representing a whole program, including all necessary libraries, then implementing Catch would be a weekends work. Thanks Neil On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell ndmitch...@gmail.com wrote: ... exhaustive pattern checking might well help out a lot of people coming from untyped backgrounds... Or even people from typed backgrounds. I worship at the altar of exhaustiveness checking. Do you really want exhaustiveness, or is what you actually want safety? With -fwarn-incomplete-patterns: test1 = head [] test2 = x where (x:xs) = [] test3 = (\(x:xs) - 1) [] test4 = f [] where f [] = 1 GHC reports that test4 has incomplete patterns, but the others don't. However, test4 is safe, but the others aren't. Exhaustiveness is a poor approximation of safety. GHC's exhaustiveness checker is a poor approximation of exhaustiveness. 2 is a poor approximation of pi :-) Using Catch, it reports that test1..3 were faulty, but test4 is safe. Thanks Neil ___ 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
baffling manual sections
I'm a little puzzled by these seeming duplicate pages in the manual: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type-extensions.html They give slightly different section numbers to similar stuff. The former page also has a curious discussion of standalone deriving with a `for` keyword: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving -- Jason Dusek ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: baffling manual sections
On Tue, May 19, 2009 at 16:07, Jason Dusek jason.du...@gmail.com wrote: The former page also has a curious discussion of standalone deriving with a `for` keyword: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving Without this extension, adding an Eq implementation to a data type for which you do not have source requires an explicit class declaration, even if there is no reason the original data type author couldn't have written deriving Eq. Standalone deriving allows you to get the convenience of deriving classes everywhere, not just on datatypes for which you can obtain, and use, the source. Denis ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.8.1 on ubuntu jaunty
Hello, I need ghc 6.8.1 for a codebase that depends on it and I'm having trouble building it on the current ubuntu. Error output attached. Martin configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h Configuring network-2.1.0.0... rm -f network/GNUmakefile cp Makefile.local network if ifBuildable/ifBuildable network; then \ cd network setup/Setup makefile -f GNUmakefile; \ fi Socket.hsc: In function ‘main’: Socket.hsc:1143: error: invalid application of ‘sizeof’ to incomplete type ‘struct ucred’ Socket.hsc:1143: error: invalid application of ‘sizeof’ to incomplete type ‘struct ucred’ Socket.hsc:1143: error: invalid application of ‘sizeof’ to incomplete type ‘struct ucred’ Socket.hsc:1149: error: invalid use of undefined type ‘struct ucred’ Socket.hsc:1150: error: invalid use of undefined type ‘struct ucred’ Socket.hsc:1151: error: invalid use of undefined type ‘struct ucred’ compiling dist/build/Network/Socket_hsc_make.c failed command was: gcc -c -D__GLASGOW_HASKELL__=608 -I/tmp/ghc-6.8.1/includes -I/tmp/ghc-6.8.1/gmp/gmpbuild -D__GLASGOW_HASKELL__=608 -DCALLCONV=ccall -Iinclude dist/build/Network/Socket_hsc_make.c -o dist/build/Network/Socket_hsc_make.o Preprocessing library network-2.1.0.0... make[1]: *** [network/GNUmakefile] Error 1 make[1]: Leaving directory `/tmp/ghc-6.8.1/libraries' make: *** [stage1] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Closure elimination transformation (continuation style passing code)
On May 19, 2009 22:17:39 Tyson Whitehead wrote: 2- specialize count for step = iter snip 3- specializing iter for next = count snip I changed this just before sending it and managed to goof step two and three (the specializations). The whole thing, with the correct steps two and three should have been the following 1- avoid forming the (iter xs) and (count i+1) closures by passing the function and the arguments instead of the function bound to the argument iter [] next i done = done iter (x:xs) next i done = next i x iter xs count i x step xs = step xs count (i+1) (i+1) test xs = iter xs count 0 0 2- specialize iter for next = count iter [] next i done = done iter (x:xs) next i done = next i x iter xs iter' [] i done = done iter' (x:xs) i done = count i x iter xs count i x step xs = step xs count (i+1) (i+1) test xs = iter' xs 0 0 3- specialize count for step = iter (and use the specialized iter') iter [] next i done = done iter (x:xs) next i done = next i x iter xs iter' [] i done = done iter' (x:xs) i done = count' i x xs count i x step xs = step xs count (i+1) (i+1) count' i x xs = iter' xs (i+1) (i+1) test xs = iter' xs 0 0 (iter and count are no longer used and can be dropped at this point) 4- inline count' iter' [] i done = done iter' (x:xs) i done = iter' xs (i+1) (i+1) count' i x xs = iter' xs (i+1) (i+1) test xs = iter' xs 0 0 (count is no longer used and can be dropped at this point) 5- eliminate the done argument as it is always the same as the i argument iter'' [] i = i iter'' (x:xs) i = iter'' xs (i+1) test xs = iter'' xs 0 As the first one does not seem to be being performed, I did it manually to see if that would be enough that GHC would pickup on the rest. It seems that this isn't the case. The second two are not being done as well. Cheers! -Tyson signature.asc Description: This is a digitally signed message part. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: baffling manual sections
On Tue, May 19, 2009 at 6:22 PM, Denis Bueno dbu...@gmail.com wrote: On Tue, May 19, 2009 at 16:07, Jason Dusek jason.du...@gmail.com wrote: The former page also has a curious discussion of standalone deriving with a `for` keyword: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving Without this extension, adding an Eq implementation to a data type for which you do not have source requires an explicit class declaration, even if there is no reason the original data type author couldn't have written deriving Eq. Standalone deriving allows you to get the convenience of deriving classes everywhere, not just on datatypes for which you can obtain, and use, the source. Denis ___ I think what he's referring to is that StandaloneDeriving actually has the syntax deriving instance Eq Foo not deriving Eq for foo Alex ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
