Responding to a very stale thread here...
Scott Turner 2hask...@pkturner.org writes:
And indeed, a channel carrying a sum type corresponds much more
closely to a pair of channels than does a channel carrying pairs.
I certainly agree with the slogan a stream of pairs is not the same as
a pair
Sorry, forgot to CC the list. I wonder why Gmail doesn't default to reply-all.
On Fri, Apr 1, 2011 at 9:48 PM, David Barbour dmbarb...@gmail.com wrote:
If we ignore the 'delay' primitive (which lifts latency into program
logic), my model does meet all the arrow laws. Nonetheless, the issues
On Sat, Apr 2, 2011 at 10:09 AM, Paul L nine...@gmail.com wrote:
Sorry, forgot to CC the list. I wonder why Gmail doesn't default to
reply-all.
If you have keyboard shortcuts on, reply to messages with the a key
instead of the r key. I hardly ever use r.
Luke
On Fri, Apr 1, 2011 at 9:48
On Sun, Mar 20, 2011 at 10:18 PM, David Barbour dmbarb...@gmail.com wrote:
The (***) and () operations, as specified in Control.Arrow, are
inherently synchronization points.
Ideally one could do something like:
(a1 *** a2) first a3
and the output from a1 would be piped directly as input
I now understand where you are coming from, but I don't quite get your
motivation to develop new classes for arrows. Tupling is Haskell is of
course very lazy, it does not evaluate any of its element. As for the
spatial and logical concepts, don't you think they are over-specifying
what is really
Thanks for the elaboration. I now have a much better understanding.
FIrst of all, I agree that the system model as you laid out do not fit
into the arrows abstraction with respect to the set of arrow laws.
Then the choice is whether to shape the arrows to fit your model, or
shape your model to
On 2011-03-21 01:18, David Barbour wrote:
I was giving Control.Arrow a try for a reactive programming system.
The arrows are agents that communicate by sending and returning
time-varying state. Different agents may live in different 'vats'
(event-driven threads) to roughly model distributed
David,
On 21/03/2011, at 4:18 PM, David Barbour wrote:
I was giving Control.Arrow a try for a reactive programming system.
The arrows are agents that communicate by sending and returning
time-varying state. Different agents may live in different 'vats'
(event-driven threads) to roughly model
I was giving Control.Arrow a try for a reactive programming system.
The arrows are agents that communicate by sending and returning
time-varying state. Different agents may live in different 'vats'
(event-driven threads) to roughly model distributed computing. For the
most part, the state varies
