Re: [Haskell-cafe] a general question on Arrows
On Thu, Feb 14, 2008 at 12:50 AM, Steve Lihn [EMAIL PROTECTED] wrote: He described a few things that cannot be represented as a monad, they are: 1. Stream This is actually a comonad. 2. FRP Depends on which FRP you're talking about. This could be the stream comonoad + the event monad. Here's another fun arrow: http://luqui.org/blog/archives/2007/09/06/quantum-entanglement-in-haskell/ Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a general question on Arrows
1. Stream This is actually a comonad. Something more to learn everyday. Here's another fun arrow: http://luqui.org/blog/archives/2007/09/06/quantum-entanglement-in-haskell/ Luke Luke, I managed to get your quantum entanglement examples working. But honestly, I can't quite figure out your Quantum module yet. My head is exploding after reading the code :-) It is amazing to know it takes several layers of arrows to simulate the quantum mechanics. I have a small question on the simulation technique. In both John Hughes and your code, you wrap the print inside the runXYZ (...) to print out the state of simulation. It is like: runArrow ( ... simulation ...then print ...) - input Why don't you structure it like y - runArrow ( ... simulation ... then return observation ... ) - input reuse y or print y In the former, the result is printed on the screen. I can not collect the result and do more analysis. For example, for a quantum state |0 + i |1, the probability is half half. If I can repeat the simulation 1 times and collect the observations (y) , then I can prove the correctness of experiment by observing ~5000 of |0 and ~5000 of |1. Or even plot the probability distribution of the experiment. Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a general question on Arrows
On Thu, Feb 14, 2008 at 7:34 PM, Steve Lihn [EMAIL PROTECTED] wrote: I have a small question on the simulation technique. In both John Hughes and your code, you wrap the print inside the runXYZ (...) to print out the state of simulation. It is like: runArrow ( ... simulation ...then print ...) - input Why don't you structure it like y - runArrow ( ... simulation ... then return observation ... ) - input reuse y or print y After attempting to reply to this several times, I think I finally know what you're asking. Well, observe and observeWith are exported, so you could do that if you wanted. As far as why I didn't do that in my example code, uh, I dunno. Really the purpose of this was to port the Quantum::Entanglement Perl module, for no other reason than that module made me go Woah! That's awesome!. So I wanted to transliterate the Perl examples which collapsed and printed in one go, because those were what made me feel like I was inside some freaky quantum computer, not just running a simulation module. :-) Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a general question on Arrows
In John Hughes' paper [1], Programming with Arrows, p. 20, The truly interesting arrow types are those which do not correspond to a monad, because it is here that arrows give us real extra generality. Since we know that stream functions cannot be represented as a monad, then they are one of these interesting arrow types. So are the arrows used for functional reactive programming, for building GUIs, and the arrows for discrete event simulation we present in Section 5. And since these arrows cannot be represented by a monad, we know that they cannot support a sensible definition of app either. He described a few things that cannot be represented as a monad, they are: 1. Stream 2. FRP 3. GUI (request/response?) 4. Event Driven System (like circuits, robots?) My first question is: Are they absolutely outside of the realm of function + monad, therefore, arrows are indispensable? Or it is simply because the haskell program would be very cumbersome without arrows in these areas? (I mean without utilizing FFI to rescue.) The second question is: Other than the 4 areas above, are there more? Just want to get a sense of how useful arrows are. Not really a theoretical question. Thanks, Steve [1] http://www.cs.chalmers.se/~rjmh/afp-arrows.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
