Different semantics in "identical" do statement?

In my program do x <- do blah <- someFunc return blah return $ Constructor x behaves differently from do blah <- someFunc return $ Constructor blah where the dots are identical. I would think that these programs should behave identically, by the monad laws. The result of my program is that the second gives correct behaviour, while the first loops forever. Greetings, Gerben -- View this message in context: http://www.nabble.com/Different-semantics-in-%22identical%22-do-statement--t... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

In what Monad? -Ross On Oct 9, 2009, at 5:43 PM, staafmeister wrote:
In my program
do x <- do blah <- someFunc return blah return $ Constructor x
behaves differently from do blah <- someFunc return $ Constructor blah
where the dots are identical. I would think that these programs should behave identically, by the monad laws. The result of my program is that the second gives correct behaviour, while the first loops forever.
Greetings, Gerben -- View this message in context: http://www.nabble.com/Different-semantics-in-%22identical%22-do-statement--t... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com .
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Ross Mellgren wrote:
In what Monad?
Parsec Monad -- View this message in context: http://www.nabble.com/Different-semantics-in-%22identical%22-do-statement--t... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

I vaguely remember on IRC someone pointing out that the Parsec monad
broke one of the laws. I think return _|_ >> x === _|_ which could be
causing your problem. I may be wrong though.
On Fri, Oct 9, 2009 at 5:59 PM, staafmeister
Ross Mellgren wrote:
In what Monad?
Parsec Monad
-- View this message in context: http://www.nabble.com/Different-semantics-in-%22identical%22-do-statement--t... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Daniel Peebles wrote:
I vaguely remember on IRC someone pointing out that the Parsec monad broke one of the laws. I think return _|_ >> x === _|_ which could be causing your problem. I may be wrong though.
This could very well be it. I use lazy eval to construct a function that returns its own argument (that is you supply the return value of the func as its arg). -- View this message in context: http://www.nabble.com/Different-semantics-in-%22identical%22-do-statement--t... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Daniel Peebles wrote:
I vaguely remember on IRC someone pointing out that the Parsec monad broke one of the laws. I think return _|_ >> x === _|_ which could be causing your problem. I may be wrong though.
Confirmed, working in the parsec monad Prelude Text.Parsec> runP (do {x <- return undefined; return 10}) () "" "" *** Exception: Prelude.undefined In the IO Monad Prelude Text.Parsec> do {x <- return undefined; return 10} 10 Should be fixed. -- View this message in context: http://www.nabble.com/Different-semantics-in-%22identical%22-do-statement--t... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

On Fri, Oct 9, 2009 at 6:47 PM, staafmeister
Daniel Peebles wrote:
I vaguely remember on IRC someone pointing out that the Parsec monad broke one of the laws. I think return _|_ >> x === _|_ which could be causing your problem. I may be wrong though.
Confirmed, working in the parsec monad
Prelude Text.Parsec> runP (do {x <- return undefined; return 10}) () "" "" *** Exception: Prelude.undefined
In the IO Monad Prelude Text.Parsec> do {x <- return undefined; return 10} 10
Should be fixed.
It looks like the problem is a strict field in the definition of
GenParser (specifically in Reply). From what I can tell, Parsec 3.0.1
should not have this problem.
--
Dave Menendez

On Fri, Oct 9, 2009 at 4:25 PM, David Menendez
On Fri, Oct 9, 2009 at 6:47 PM, staafmeister
wrote: Daniel Peebles wrote:
I vaguely remember on IRC someone pointing out that the Parsec monad broke one of the laws. I think return _|_ >> x === _|_ which could be causing your problem. I may be wrong though.
Confirmed, working in the parsec monad
Prelude Text.Parsec> runP (do {x <- return undefined; return 10}) () "" "" *** Exception: Prelude.undefined
In the IO Monad Prelude Text.Parsec> do {x <- return undefined; return 10} 10
Should be fixed.
It looks like the problem is a strict field in the definition of GenParser (specifically in Reply). From what I can tell, Parsec 3.0.1 should not have this problem.
-- Dave Menendez
http://www.eyrie.org/~zednenem/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
It works with Parsec 3.0.1 for me. Alex
participants (5)
-
Alexander Dunlap
-
Daniel Peebles
-
David Menendez
-
Ross Mellgren
-
staafmeister