naming functions is the most difficult thing in programming

I am looking for a clear way to mark functions that return sp or ap and everything looks terrible ; P

!! and !?

does't convince me

maybe < and >?

leonoel often uses >f for flow holding variables

so functions returning flow would be consistent with this

but how will you know if it's sequential or ambiguous?

in core.async functions returning channel sometimes have > prefix

sp is a bit like go block

So maybe sp should have < prefix and ap have > prefix?

one char is better than two...

but what do < and > mean in this context?

it has no semantic meaning, except that after a function with a < prefix we can expect one value in the future, and after a > many values in the future

and imho it looks better than !! and !?, but this is a subjective feeling

| for sp and & for amb?

@U053XQP4S do you have any preferences?

currently, missionary with its sigils looks a bit like a brainfuck, and adding the remaining characters from the keyboard probably won't improve the aesthetic feeling 😜

Just suffix sync and amb?

I don't know, I'm not the decision maker either

I've never really felt the need for a naming convention. Functions returning task/flow are usually pure so there's no need for a ! IMO. The function call is very often inlined in the ? form so the task/flow itself doesn't have to be named. When needed, >f is used at hyperfiddle as a loose convention for naming signals, but it's not used that much in our codebase because we use photon as an intermediate layer. @U0BBFDED7 if a naming scheme works for you, you're totally entitled to communicate about it.

clojure is not typed and good function naming helps, at least for me

a docstring would probably suffice, but there is never enough time or willingness for that

btw, @U053XQP4S, we started using missionary on production

not me, because unfortunately I don't have the possibility, but colleagues on another project

glad to hear that ! I'd love to know more, if you and/or your colleagues want to discuss feel free to DM me

there is not much I can say and the man who runs it is a ninja who rarely leaves his cave to chat on slack

the previous project used a re-frame, which generally did not work well for us, and now a homemade solution has been created using rumext+missionary

re-frame is actually a graph too, but how the subscriptions work is mega complex, and reagent doesn't help at all

In fact, reimplementing a re-frame using missionary will probably be a <500 loc