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

[Paul L]

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 <dmbarbour at 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
> 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