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
On Thu, Feb 14, 2008 at 12:50 AM, Steve Lihn
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
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 10000 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
On Thu, Feb 14, 2008 at 7:34 PM, Steve Lihn
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
participants (2)
-
Luke Palmer -
Steve Lihn