The Data and Control distinction makes sense in many circumstances: whenever an enriched category is under focus. Depending on the category, different functors may make it on one side of the barrier or the other.
-
-
Prikaži ovu nit
-
In the category of Set (or Hask) there is no difference. Indeed many functors are used both as data and as control. For instance a list can be a container or a backtracking monad.
Prikaži ovu nit -
I use linear types in the blog post because there the difference is apparent. In fact, I've needed both kinds of functor in linear-base.
Prikaži ovu nit -
In the case of a self-enrichment, like linear types, control functors are, actually, also data functors. Some care applies!
Prikaži ovu nit -
An example of different functor making different classification depending on the category you are using: Maybe is control with affine types, but isn't with linear types.
Prikaži ovu nit -
It doesn't mean that exceptions are not control with linear types, just that exceptions are a different monad (namely `_⊕⊤`).
Prikaži ovu nit -
What distinguishes data and control, essentially, is that you can use the do-notation with control monads, but not with data monads.
Prikaži ovu nit -
The distinction is about what I can do with a functor, rather than what it is. That's why individual functors can be control or not depending on the situation.
Prikaži ovu nit -
This is why I don't speak about data monads too much in the blog post: they are less evidently useful. You can still use them to model substitution (e.g. in first-order terms).
Prikaži ovu nit -
With linear types, lists form a data monad, but not a control monad. This is witnessed by the fact that the do-notation, on lists, lets me make cartesian products, which are definitely not linear.
Prikaži ovu nit -
This also proves, incidentally, that data applicative are not a super-class of data monads since lists are the latter, but not the former (control applicative, however, are a super-class of control monads).
Prikaži ovu nit -
I didn't speak about `Traversable` at all, but traversable functors do belong in the data hierarchy (I don't believe there is any value in coming up with a control equivalent of traversables but I'd be thrilled to be wrong!)
Prikaži ovu nit -
This do-notation business has been known since before the monads were a thing in Haskell: Moggi needed *strong* monads to give semantics to effects. In a self-enriched category, strong monads and enriched monads are the same.
Prikaži ovu nit -
Only it hadn't been connected to the data/control intuition before. It's a cute little story. The strength requirement is often forgotten because of how all monads are strong (aka enriched) in Hask.
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.