Re: [Haskell-cafe] Newbie and working with IO Int and Int

newer
Re: Lexically scoped type variables

Víctor A. Rodríguez

17 Oct 2006 17 Oct '06

1:37 p.m.

What's wrong with doing it this way?

-- ** UNTESTED CODE **

verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum | a + b == sum = True otherwise = False

testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b)

-- all the IO-dependent stuff is below this line --

testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return verifyAdd a b (a + b)

I discovered something worst yet :-P Using the next code and calling verifyAdd or testAddMundane it says : Program error: verifyAdd: ERROR Instead calling testAddRandom only says : :: IO Bool (55 reductions, 92 cells) ---- CODE STARTS HERE, AND IS TESTED ----- import Random verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum = error "verifyAdd: ERROR" testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b) -- all the IO-dependent stuff is below this line -- testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return ( verifyAdd a b (a+b) ) -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

Show replies by date

Robert Dockins

17 Oct 17 Oct

1:44 p.m.

New subject: Newbie and working with IO Int and Int

On Oct 17, 2006, at 1:37 PM, Víctor A. Rodríguez wrote:

...

...
What's wrong with doing it this way?

-- ** UNTESTED CODE **

verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum | a + b == sum = True otherwise = False

testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b)

-- all the IO-dependent stuff is below this line --

testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return verifyAdd a b (a + b)

I discovered something worst yet :-P Using the next code and calling verifyAdd or testAddMundane it says :

Program error: verifyAdd: ERROR

Instead calling testAddRandom only says :

:: IO Bool (55 reductions, 92 cells)

This is due to the magic of lazy evaluation. You never use the result of 'testAddRandom', so it's never evaluated, which means your call to 'error' is also never evaluated. Type: testAddRandom >>= print on the command line and you should get the same error, because the call to 'print' demands the result of running testAddRandom.

...

---- CODE STARTS HERE, AND IS TESTED -----

import Random

verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum = error "verifyAdd: ERROR"

testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b)

-- all the IO-dependent stuff is below this line --

testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return ( verifyAdd a b (a+b) )

-- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

Daniel Fischer

3 p.m.

New subject: Newbie and working with IO Int and Int

Am Dienstag, 17. Oktober 2006 19:37 schrieb Víctor A. Rodríguez:

...

...
What's wrong with doing it this way?

-- ** UNTESTED CODE **

verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum | a + b == sum = True otherwise = False

testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b)

-- all the IO-dependent stuff is below this line --

testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return verifyAdd a b (a + b)

I discovered something worst yet :-P Using the next code and calling verifyAdd or testAddMundane it says :

Program error: verifyAdd: ERROR

Instead calling testAddRandom only says : :: IO Bool

(55 reductions, 92 cells)

Well, that's absolutely correct. 'return (error "ERROR")' is different from 'error "ERROR"' and is a perfectly well-behaved monadic value. As long as you don't try to evaluate the returned value (e.g. for printing it), it doesn't trigger the error (remember, Haskell is lazy!). And by default, hugs doesn't print the results of IO-actions: Hugs> putStrLn "No result" No result Hugs> :set +I Hugs> putStrLn "No result" No result () <- this is the result of the IO-action putStrLn "No Result" The option +I says you want the results of IO-actions to be printed, and indeed: Verify> :set +I Verify> testAddRandom Program error: verifyAdd: ERROR The same, if we explicitly ask for the result to be printed if the +I option isn't set: Verify> testAddRandom >>= print Program error: verifyAdd: ERROR ghci-6.6 does so by default (for some IO-actions, not for e.g. putStrLn ".."): *Verify> testAddRandom *** Exception: verifyAdd: ERROR Prelude System.CPUTime> t <- getCPUTime 130000000000 and ghci-6.4.2 like hugs needs to be asked for the result of the IO-action *Verify> r <- testAddRandom *Verify> r *** Exception: verifyAdd: ERROR *Verify> testAddRandom *Verify> it *** Exception: verifyAdd: ERROR Now let's use the result of testAddRandom: testAnew :: IO () testAnew = do b <- testAddRandom print (True || b) print (False && b) print b b is bound to the result of testAddRandom, i.e. error "verifyAdd: ERROR", but it is not evaluated until needed, so True and False get printed before the exception is raised when we ask for it to be printed. *Verify> testAnew True False *** Exception: verifyAdd: ERROR HTH, Daniel

...

---- CODE STARTS HERE, AND IS TESTED -----

import Random

verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum = error "verifyAdd: ERROR"

testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b)

-- all the IO-dependent stuff is below this line --

testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return ( verifyAdd a b (a+b) )

-- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Ketil Malde

18 Oct 18 Oct

3:35 a.m.

New subject: Newbie and working with IO Int and Int

Daniel Fischer writes:

...

ghci-6.6 [prints the result of IO actions] by default

I consider printing the value when it is used in an assignment a bug. It makes it more difficult to test laziness issues or behavior on e.g. large files. Anybody know why it was changed to the current behavior? -k -- If I haven't seen further, it is by standing in the footprints of giants

Daniel Fischer

7:04 a.m.

New subject: Newbie and working with IO Int and Int

Am Mittwoch, 18. Oktober 2006 09:35 schrieb Ketil Malde:

...

Daniel Fischer writes:

...
ghci-6.6 [prints the result of IO actions] by default

I consider printing the value when it is used in an assignment a bug. It makes it more difficult to test laziness issues or behavior on e.g. large files.

Seconded: Prelude> txt <- readFile "Grid11.txt" "08 02 22 97 38 15 00 40 00 75 04 05 07 78 52 12 50 77 91 08\n49 49 99 40 17 81 18 57 60 87 17 40 98 43 69 48 04 56 62 00\n81 49 31 73 55 79 14 29 93 71 40 67 53 88 30 03 49 13 36 65\n52 70 95 23 04 60 11 42 69 24 68 56 01 32 56 71 37 02 36 91\n22 31 16 71 51 67 63 89 41 92 36 54 22 40 40 28 66 33 13 80\n24 47 32 60 99 03 45 02 44 75 33 53 78 36 84 20 35 17 12 50\n32 98 81 28 64 23 67 10 26 38 40 67 59 54 70 66 18 38 64 70\n67 26 20 68 02 62 12 20 95 63 94 39 63 08 40 91 66 49 94 21\n24 55 58 05 66 73 99 26 97 17 78 78 96 83 14 88 34 89 63 72\n21 36 23 09 75 00 76 44 20 45 35 14 00 61 33 97 34 31 33 95\n78 17 53 28 22 75 31 67 15 94 03 80 04 62 16 14 09 53 56 92\n16 39 05 42 96 35 31 47 55 58 88 24 00 17 54 24 36 29 85 57\n86 56 00 48 35 71 89 07 05 44 44 37 44 60 21 58 51 54 17 58\n19 80 81 68 05 94 47 69 28 73 92 13 86 52 17 77 04 89 55 40\n04 52 08 83 97 35 99 16 07 97 57 32 16 26 26 79 33 27 98 66\n88 36 68 87 57 62 20 72 03 46 33 67 46 55 12 32 63 93 53 69\n04 42 16 73 38 25 39 11 24 94 72 18 08 46 29 32 40 62 76 36\n20 69 36 41 72 30 23 88 34 62 99 69 82 67 59 85 74 04 36 16\n20 73 35 29 78 31 90 01 74 31 49 71 48 86 81 16 23 57 05 54\n01 70 54 71 83 51 54 69 16 92 33 48 61 43 52 01 89 19 67 48\n" Not good, IMHO.

...

Anybody know why it was changed to the current behavior?

-k

Cheers, Daniel

6790

Age (days ago)

6791

Last active (days ago)

List overview

Download

4 comments

4 participants

participants (4)

Daniel Fischer
Ketil Malde
Robert Dockins
Víctor A. Rodríguez