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
On Sat, Apr 2, 2011 at 10:09 AM, Paul L 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 PM, David
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 wrote:
>
> If we ignore the 'delay' primitive (which lifts latency into program
> logic), my model does meet all the arrow laws. Nonetheless, the issues
> of physical synch
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
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 fi
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 n
On Sun, Mar 20, 2011 at 10:18 PM, David Barbour 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 to a3
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 mo
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 as
