Re: [Haskell-cafe] Asynchronous Arrows need Type Specialization - Help!

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 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 synchronization still apply. It's important to recognize that the Arrow Laws do not describe non-functional properties, such as time-space performance.

Well, when you throw the time stamp into the value domain, and according to your previous calculation of time stamps, (a1 *** a2)

...

...

...

first a3 will produce different result than (a1 >>> a3) *** a2. This is in direct conflict to arrow laws.

Arrows by themselves do not impose physical synchronization. They are very often used to model computations about synchronous data streams, but that is a very different concept.

...

...

In the actual implementation of such lifting (perhaps over multiple type classes), the calculation of the time stamp can be made precise.

Indeed. And it is precisely the greater of the input timestamps. ;-)

This is because you are using a single number as timestamp. Define your timestamp type differently, you'll get a different opinion. For example, you can use a pair of time stamps for pairs, and nested time stamps for nested values.

-- Regards, Paul Liu

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe