I liked your discussion about comonads, and, as I used the concept to describe “realized” constants, I linked your post into my article “Realized Constants are Comonadic“.

I had started exploring comonadic structures before for you posted your description, and I felt the loss, as they are a really simple concept, but other than Edward Kmett’s (very excellent) site and sigfpe’s blog, there seemed to be little interest in them.

Thank you for bringing this useful concept to the fore.

cheers, geophf

]]>`((:->#) t)`

satisfying the comonad laws.
I like your question about relating our abstractions to standard algebraic notions embodied by type classes. I appreciate the “syntactic” (so to speak) and semantic benefits. By syntactic, I mean inheriting a standard vocabulary so that I don’t have to define so much of it myself. That vocabulary guides me to tools that I might not have thought to try out. By “semantic benefits”, I mean both the class laws, as you mentioned, and the semantic morphisms.

For instance, much of the syntactic and semantic foundation of FRP (the explicit signal variety) can be captured via class instances and the corresponding type class morphisms. When those morphisms hold, I know I’m in the universal flow, rather than just making stuff up. I’m confident that my formalism will be powerful, predictable, and a pleasure to use. When the morphisms fail, or aren’t even defined, as currently with Reactive events, I know to expect pain and where to start when trying to improve things.

For signals in particular, `Applicative`

has been great, since it (or `Zip`

) captures the essence of concurrent composition.
And the semantic model and applicative morphism tell us exactly what the `Applicative`

instance must mean.

A question I’m always asking myself is that, do we gain anything from declaring signals (both behaviors and events) an instance of such abstract formalisms like Comonad or Applicative Functor?

Sure, we get a few primitives to write program with and some nice properties (i.e., the laws) associated with them. But do they help? To what extent?

I for one do not think Applicative Functor provides any more insights than Functors except some coding convenience perhaps. As for Comonad, I don’t know, the laws are actually more interesting than those of Applicative Functors, but I’m not sure how to make use of them.

]]>I think choosing a proper set of functions that create comonadic values (other than what’s provided in the definition of a comonad) should be enough to enforce causality. I haven’t done enough work on this to say for certain, though.

]]>`((:->#) t)`

passes or fails?
]]>`Segment`

class.
`drop`

could indeed go into another class, since it works for infinite-only types like `(t -> a)`

(for ordered infinite `t`

) as well as for possibly-finite ones like `[a]`

and `(t :-># a)`

.
`take`

yields a finite result, so I think would be problematic.
]]>