Re: [Haskell-cafe] QuickCheck, (Ord a)= [a] - Property problem
larry.liuxinyu liuxiny...@gmail.com writes: Somebody told me that: Eduard Sergeev • BTW, more recent QuickCheck (from Haskell Platform 2011.2.0.X - contains QuickCheck-2.4.0.1) seems to identifies the problem correctly: *** Failed! Falsifiable (after 3 tests and 2 shrinks): [0,1] False I don't think this can be true: the problem occurs in GHCi and there's no way for QuickCheck to detect it. And when I tested it I got the same problem. There must be some difference between the properties you both tested... Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck, (Ord a)= [a] - Property problem
larry.liuxinyu liuxiny...@gmail.com writes: prop_foo :: (Ord a) = [a] - Property prop_foo xs = not (null xs) == maximum xs == minimum xs This is an extreme case that the property is always wrong. However, QuickCheck produces: *Main test prop_foo OK, passed 100 tests. Why this happen? If I use verboseCheck, I can find the sample test data are as the following: *MainverboseCheck prop_foo ... 97: [(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),()] 98: [(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(), (),(),(),(),(),(),()] 99: [(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(), (),(),()] OK, passed 100 tests. This is an unfortunate feature of GHCi: if the thing you want to evaluate has a polymorphic type then all the type variables default to (), see: http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/interactive-evaluation.html#extended-default-rules So prop_foo is only tested for lists of (). Nasty. The usual way to work around it is to declare all your properties monomorphic, so write: prop_foo :: [Integer] - Property This works at least, However, since 'a''b', they are order-able, what if I want to test prop_foo works for char? Testing with Integers should always[*] be enough because of parametricity. Nick [*] For certain values of always :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: OT: Literature on translation of lambda calculus to combinators
Job Vranish jvran...@gmail.com writes: Ideally we'd like the type of convert to be something like: convert :: LambdaExpr - SKIExpr but this breaks in several places, such as the nested converts in the RHS of the rule: convert (Lambda x (Lambda y e)) | occursFree x e = convert (Lambda x (convert (Lambda y e))) A while ago I tried modifying the algorithm to be pure top-down so that it wouldn't have this problem, but I didn't have much luck. Anybody know of a way to fix this? The way to do it is, when you see an expression Lambda x e, first convert e to a combinatory expression (which will have x as a free variable, and will obviously have no lambdas). Then you don't need nested converts at all. Not-really-tested code follows. Nick data Lambda = Var String | Apply Lambda Lambda | Lambda String Lambda deriving Show data Combinatory = VarC String | ApplyC Combinatory Combinatory | S | K | I deriving Show compile :: Lambda - Combinatory compile (Var x) = VarC x compile (Apply t u) = ApplyC (compile t) (compile u) compile (Lambda x t) = lambda x (compile t) lambda :: String - Combinatory - Combinatory lambda x t | x `notElem` vars t = ApplyC K t lambda x (VarC y) | x == y = I lambda x (ApplyC t u) = ApplyC (ApplyC S (lambda x t)) (lambda x u) vars :: Combinatory - [String] vars (VarC x) = [x] vars (ApplyC t u) = vars t ++ vars u vars _ = [] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
