Just finished another chapter of control flow categorical primitive internals in Я - Kleisli morphisms. Coupled with matching natural transformations you are able do define Monads and Traversable functors.
4 Likes
Actually I have a question I was too afraid to ask since previous posts.
How do I see control flow in all this?
Currently I only see iterating over data. But that is called data processing, even data flow, not control flow. For example, SQL does a lot of iterating over data too, probably more in some aspects, but is known as a data something-something language rather than a control flow language.
2 Likes
How do I see control flow in all this?
I honestly don’t understand your question… What should you see to say it’s a part of control flow primitives? I probably can give you some examples.
Control flow constructs are conditional: in Haskell, if and case expressions, guards, and the patterns in function clauses. The flow of computation depends on the value of data. Something like a map over a list doesn’t, at first glance, demonstrate control flow, because the mapped function is applied uniformly to every element of the list. There’s no opportunity to change the behavior of the map in the middle.
A traverse can be used with control flow constructs—if the applicative functor holding the effects is something like Maybe, then a mid-traversal Nothing aborts the flow of computation—but it isn’t the traverse function that’s doing that, it’s the implementation of (<*>) in Applicative Maybe, which necessarily uses one of the aforementioned control flow constructs in Haskell (or calls a function that does so).
Are traversals in your backwards-R language different—do they actually describe control flow themselves? It doesn’t seem so, from what I can tell.
If you mean only conditionals by “control flow primitives” I think it’s pretty far from original definition:
In computer science, control flow (or flow of control ) is the order in which individual statements, instructions or function calls of an imperative program are executed or evaluated. The emphasis on explicit control flow distinguishes an imperative programming language from a declarative programming language.
Sure you can express conditionals in Я with colimits. But this chapter is planned to be published after monoidal functors (next one).
You can also use monoidal functors (with a Day convolution from product to sum) to form a “branch selection”, it’s similar to Alternative in Haskell.
Stay tuned. 
1 Like
I suppose I should have said ‘control flow in a lazy functional language’, because you’re right; in imperative languages there are more control flow constructs.
But the point stands: at least in Haskell, we’re encouraged to think of things like fmap as not having anything to do with control flow, because without side effects there is no difference between a map that is computed back-to-front or front-to-back or in random order. The usual pseudo-category theory used to model Haskell informally captures this too. You’re wielding a lot of category theory concepts in your posts but I remain unclear on which of those concepts are sufficiently different from how they’re used by Haskellers such that questions of ‘order of execution of individual statements’ or anything like that suddenly become relevant.
we’re encouraged to think of things like
fmapas not having anything to do with control flow
And that is the problem. If you map a Kleisli morphism instead of a flat one - you already can encode branch selection. So that binding and traversals are maps too, they just involve Kleisli morphisms. I think this part I explained in details.
That’s the problem of “monads explained easy” content, they give you wrong perceptions that stick to you for a long time. These chapters I write could look too abstract but they do not limit your imagination.
without side effects there is no difference between a map that is computed back-to-front or front-to-back
Here is the example of using different traversal order to process a list: Я ☞ Tutorials ☞ Trapping rain water - 1
Traversal order and evaluation order aren’t the same thing, though! Threading a computation through a list in two directions introduces a data flow between elements. I still don’t see a control flow here.
(I’m not sure this is a perfectly faithful translation of the solution in the tutorial, but the explanation seems pretty close to the Tardis monad, so here’s a Haskell implementation:
import Control.Monad.Tardis
-- | Return the amount of trapped water given a list of levels.
tap :: [Int] -> Int
tap = sum . flip evalTardis (0, 0) . traverse \level -> do
right <- getFuture
modifyBackwards (max level)
modifyForwards (max level)
left <- getPast
pure $ min left right - level
If this is a reasonably faithful translation, then again I ask: where’s the control flow? ‘Evaluation order’ (not in the pure sense, but in the inside-a-monad sense) matters inside the do block here, between the various Tardis operations. The whole point of traverse is that it doesn’t involve itself with any of that control flow—it’s all delegated to the applicative functor. So if I were to present traverse to a Haskell learner as a control-flow primitive, I think I’d be missing the point pretty hard!)
Traversal order and evaluation order aren’t the same thing, though!
In this case effects are evaluated in reverse order as well.
but the explanation seems pretty close to the Tardis monad
Close, but anyway it’s different. In Tardis monad you cannot run IO effects backwards.
I still don’t see a control flow here.
I cannot really help you here, I’m sorry. Finding examples that are close but still don’t get to the point is not going to help here. Neither I have any wish to start an argument over different interpretations of control flow.
1 Like
I honestly don’t understand your question… What should you see to say it’s a part of control flow primitives? I probably can give you some examples.
Thanks for asking, and I should have told first. My examples are goto, call/cc, shift/reset, yield, or even appealing to Guy Steele’s “lambda: the ultimate goto”.
But sorry I won’t buy “all monads count as control flow because some examples of monads count as control flow”. Does the Giry probability monad count as control flow? I think no, and I think it is not even data; it’s measure theory.
2 Likes
My examples are goto, call/cc, shift/reset, yield
In previous chapter it is stated that CPS and direct style are isomorphic. So you want to say that one style is considered as control flow and another one is not? Then why?
But sorry I won’t buy “all monads count as control flow because some examples of monads count as control flow”
Can you please point me where it is written exactly?
There are no monads in Я though (and it’s mentioned in this chapter) - so I would assume that you didn’t read this chapter accurately. And I don’t sell you anything, by the way.