Re: [Haskell-cafe] Remember the future
Dan Piponi wrote: On 8/17/07, Dan Piponi [EMAIL PROTECTED] wrote: On 8/17/07, Andrew Coppin [EMAIL PROTECTED] wrote: That sounds completely absurd to me... can anybody explain? Except...you can switch on ghc's special time travel features... On reflection I decided my example isn't very convincing. For one thing, I've argued in another thread that monads aren't really about sequencing actions. But I concede that there is an exception: the IO monad. Because the IO monad has observable side effects you can actually see whether or not an action has taken place at a particular time, so it really does have to sequence actions. So now consider the following code: import IO import Control.Monad.Fix test = mdo z - return $ x+y print Hello x - readLn y - readLn return z Evaluate test and you'll be prompted to enter a pair of numbers. You'll then be rewarded with their sum. But the Hello message is printed before the prompt for input so we know that's being executed first. And we can see clearly that the summation is performed before the Hello message. So clearly this program is computing its result before receiving the input. At this point your natural reaction should be to replace 'print Hello' with 'print z'... Surely all this means is that the magical mdo keyword makes the compiler arbitrarily reorder the expression...? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Remember the future
On 8/18/07, Andrew Coppin [EMAIL PROTECTED] wrote: Surely all this means is that the magical mdo keyword makes the compiler arbitrarily reorder the expression...? What mdo actually does is described here: http://www.cse.ogi.edu/PacSoft/projects/rmb/mdo.pdf My last example desugars to: test = mfix ( \ ~(x,y,z,v) - do z - return $ x+y print Hello x - readLn y - readLn v - return z return (x,y,z,v)) = \(x,y,z,v) - return v So at core there really is a do-expression that's passing 'return $ x+y' into a print which in turn is passed into the 'readLn's. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Remember the future
I've seen comments in various places that monads allow you to borrow things from the future. That sounds completely absurd to me... can anybody explain? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Remember the future
Gwern Branwen wrote: On 0, Andrew Coppin [EMAIL PROTECTED] scribbled: I've seen comments in various places that monads allow you to borrow things from the future. That sounds completely absurd to me... can anybody explain? Take a look at issue 6 of The Monad Reader; search for time travel. http://www.haskell.org/haskellwiki/The_Monad.Reader Mmm... yes... I've read this before. It didn't make any sense then either. (The example is too big and complicated. It obscures the thing it's trying to illustrate...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Remember the future
On 8/17/07, Andrew Coppin [EMAIL PROTECTED] wrote: I've seen comments in various places that monads allow you to borrow things from the future. That sounds completely absurd to me... can anybody explain? Suppose you buy into the notion that monads sequence actions. Then consider the following code: import Control.Monad.State test = do put $ x+1 x - return 1 return undefined go = execState test undefined execState runs a sequence of actions in the state monad, ignoring the returned value and simply giving you back the resulting state. So work through what this code does: It sets the value of the state to be 1+x. It then sets x to be 1. And then it returns undefined. We don't care about the return value, we just care about the state. And clearly the state is 2. But if you believe all that action sequencing stuff, we set the state using x before we actually set the value of x. So we're reading from the future. But you can breathe a sigh of relief because the above code doesn't compile and the laws of physics remain unharmed. Except...you can switch on ghc's special time travel features using the -fglasgow-exts flag. Use the time-travel compatible mdo instead of do and you'll find that this compiles and runs fine: import Control.Monad.State import Control.Monad.Fix test = mdo put $ x+1 x - return 1 return undefined go = execState test undefined -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Remember the future
On 8/17/07, Dan Piponi [EMAIL PROTECTED] wrote: On 8/17/07, Andrew Coppin [EMAIL PROTECTED] wrote: That sounds completely absurd to me... can anybody explain? Except...you can switch on ghc's special time travel features... On reflection I decided my example isn't very convincing. For one thing, I've argued in another thread that monads aren't really about sequencing actions. But I concede that there is an exception: the IO monad. Because the IO monad has observable side effects you can actually see whether or not an action has taken place at a particular time, so it really does have to sequence actions. So now consider the following code: import IO import Control.Monad.Fix test = mdo z - return $ x+y print Hello x - readLn y - readLn return z Evaluate test and you'll be prompted to enter a pair of numbers. You'll then be rewarded with their sum. But the Hello message is printed before the prompt for input so we know that's being executed first. And we can see clearly that the summation is performed before the Hello message. So clearly this program is computing its result before receiving the input. At this point your natural reaction should be to replace 'print Hello' with 'print z'... -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Remember the future
Andrew Coppin writes: I've seen comments in various places that monads allow you to borrow things from the future. That sounds completely absurd to me... can anybody explain? Actually, borrowing from the future - in an interpretation which is close to my own interests - doesn't need monads, but *laziness*. If you find this absurd, I propose that you have a look on something a bit light, my paper on a quite crazy way to compute PI with a high precision. The algorithm (not mine, but of Bailey, Borwein and Plouffe) is a masterpiece of numerical math, but its implementation relies on a mad borrowing from the future. http://users.info.unicaen.fr/~karczma/arpap/lazypi.pdf If you don't choke, try another one, the reverse automatic differentiation algorithm, implemented using a variant of the Wadler's counter-temporal state monad. http://users.info.unicaen.fr/~karczma/arpap/revdf1.pdf It is quite serious, although inefficient, and has some affinities to the lazy processing of inherited attributes during parsing. More recently, Barak Pearlmutter and Jeff Siskind worked on similar issues, but I am not sure whether they submitted something ready for the audience. Please check it out. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Remember the future
[EMAIL PROTECTED] wrote: Andrew Coppin writes: I've seen comments in various places that monads allow you to borrow things from the future. That sounds completely absurd to me... can anybody explain? Actually, borrowing from the future - in an interpretation which is close to my own interests - doesn't need monads, but *laziness*. While this is true, the mdo and associated MonadFix class do implement it in a monadic framework where you can write things like mdo x - f y y - g x If you interpret do-notation as equivalent to imperative programming then this does indeed look like time travel. Under the covers its more equivalent to let x = f y y = g x which is also known as tying the knot or the credit card transform (both keywords worth looking up). However I can't say I really have my head around it properly. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
