add flow/for macro

[dchelimsky]

Problem: apply the same flow to different sets of inputs

Some existing solutions:

• defn a fn that returns a flow and invoke it from a defflow

(defn a-flow [arg] (flow (str "do something with " arg) ,,,)

(defflow do-something-with-x (a-flow 'x))
(defflow do-something-with-y (a-flow 'y))
;; or
(defflow do-something-with-x-and-y
  (a-flow 'x)
  (a-flow 'y))

• use cats.core/sequence directly

(defflow do-something-with-x-and-y
  (cats.core/sequence
    (for [z [:x :y]]
      (flow (str "do stuff with " z)
       ,,,
       ))))

Proposal

This PR adds a state-flow.api/for macro that works just like clojure.core/for, but returns a flow which wraps a sequence of flows, e.g.

(defflow do-something-with-x-and-y
  (flow/for [z [:x :y]]
    (flow (str "do stuff with " z)
     ,,,
     ))))

TODO:

• more doc

[sovelten]

I don't think I would be a user of this macro, but I understand if people want to use it.

I do think this is general enough to be part of https://github.com/nubank/cats/blob/master/src/cats/core.cljc though. It works for any monad, so it is kind of syntactic sugar for m/sequence

[dchelimsky]

I don't think I would be a user of this macro, but I understand if people want to use it.

I do think this is general enough to be part of https://github.com/nubank/cats/blob/master/src/cats/core.cljc though. It works for any monad, so it is kind of syntactic sugar for m/sequence

I'm happy to submit a separate PR for cats, but I also like the idea of having this in state-flow so it's obvious to state-flow users.

[dchelimsky]

it is kind of syntactic sugar for m/sequence

I agree, but I think that (m/sequence (for [,,,] many-lines-of-flows)) is easier to scan than (m/sequence (map (fn [,,,] many-lines-of-flows) seq-of-args), so I want to encourage for for consistency.

[dchelimsky]

I don't think I would be a user of this macro, but I understand if people want to use it.
I do think this is general enough to be part of https://github.com/nubank/cats/blob/master/src/cats/core.cljc though. It works for any monad, so it is kind of syntactic sugar for m/sequence

I'm happy to submit a separate PR for cats, but I also like the idea of having this in state-flow so it's obvious to state-flow users.

funcool/cats#241

[sovelten]

should this be implemented here or in another namespace, such as in state-flow.state?

[dchelimsky]

It's not really a state fn, but it's not really core for state-flow either. We could add a new namespace like state-flow.monad, but that might be confusing/distracting. Other ideas?

What about state-flow.compose? That might encourage thinking about some other ideas for composing flows.

[FelipeCortez]

I vote for state-flow.compose

[sovelten]

the state is actually a state monad so there should be the place IMO, it is in the same spirit of fmap. Not that I have a strong opinion about it.

[sovelten]

In case you want to use this helper in core.clj, core.clj depends on the state.clj, but it should not depend on state-flow.api, the hierarchy looks like this:

state
|
core
|
api

things that are more fundamental than core go in the state

[dchelimsky]

The struggle I'm having is that e.g. swap-state is clearly about state, whereas for is about composing flows. I've already merged this but we can always move it somewhere else later and reference it from api as we do with all the other functions.

[dchelimsky]

whereas for is about composing flows.

And composing flows seems more fundamental than even state to me :)

[FelipeCortez]

I don't think I would be a user of this macro, but I understand if people want to use it.
I do think this is general enough to be part of https://github.com/nubank/cats/blob/master/src/cats/core.cljc though. It works for any monad, so it is kind of syntactic sugar for m/sequence

I'm happy to submit a separate PR for cats, but I also like the idea of having this in state-flow so it's obvious to state-flow users.

not very long ago I struggled when migrating a test because there was nothing out-of-the-box like this in state-flow, and using cats like the documentation suggested felt a bit wrong, so +1. I think this is also in line with the idea that you don't have to know about the state monad to use state-flow