# About dataflow area

I'm very appreatite the work J.S.Choi and Tab did. However, one problem of it is, it only list hack style pipeline, not list all varities of the pipeline operators, and other solutions which do not have the official proposal. We should notice that even do expression could be one of the solution of dataflow.

// don't laugh, it just work!
async function test() {
  // ...
  let result = do {
    var $_ = await fetch(url)
    $_ = await $_.json()
    process($_)
  }
}

Of coz not all proposals in the picture we want to put into languages, but overlap doesn't mean all these proposals have same goal and cover same use cases. Obviously do expressions have their own core usage so even it cover some part of dataflow, we're ok of it. Similarly, the goal of PFA / Extensions is not dataflow.

PFA could be used with any other proposal in the picture, especially augment F# style pipeline which not listed in the article. PFA also could be used to solve `o.method.bind(o)` issue.

And Extensions, is the JS version of extension methods/properties feature in other mainstream OO languages. Basically all important mordern application programming languages already add it in last fifteen years, very like how async/await is added to many langauges these years. It have been proved that it's a integral part of modern OO langauges.

And this JS version Extensions even have a much large picture. `::` (or possible other symbol like `->`) is introduced, is not a simple operator only for extensions, but could be seen as a customizable `.`. With the dispatching mechanism of extensions, it could be used to meet many syntax requirements in other proposals (like first-class protocol, eventual send, invoking public methods/accessors statically, etc.), note these syntax requirements are normally very hard to solve, because we do not have much syntax space, especially method/accessors-like, we already have tough time of private method/field/accessor syntax, it's even harder to get another three or four.

It also solve many use cases related to methods/accessors (safe invoking, transpiler target static type language, safe polyfill for prototype methods/accessors, tree-shaking friendly methods/accessors etc.), and provide a "poor man's custom operators" solution for userland, greatly relieves the committee pressure of the various syntax sugar demands.

Extensions, could be used to solve dataflow problem more or less, even it's not designed for that, because it's just generalized methods/accessors, so it just augment the classic method chaining or flurent API pattern. It's not the core goal of extensions to solve dataflow issue, and I never think method chaining is a general pipe solution, but notablly, it could be used to solve unary function pipe problem in userland (`value::UserLandExtension:pipe(f1, f2, ...)`), or even provide a built-in pipe operator like `value::do:pipe(func1, func2, ...)`.

To clarify, it doesn't mean Extensions make F# style pipeline totally useless, it just provide an alternative solution if we can't have F# style pipeline (to satisfy FP fans who are disappoied with Hack style). Again, Extensions is actually a more general mechnism, it could mimic almost all infix and postfix operators (and we already have function as prefix op), in unified method-like form, but not optimize for special usage. It give the committe a much freedom to explore and choose differnt solutions:

leave to userland, builtin meta extensions, or dedicated syntax.

---

Currently , Hack style seems the general solution for dataflow problem. But is a general solution always good?

We should note, all these proposals do not provide any fundamental new power, so the main point is ergnomics, at least in dataflow use cases, this is what we need to care. But ergnomics is not general , it's highly context related.

We should notice, methods/accessors have the most serious ergnomics problem, both Extensions and bind-this proposal caught this pain point. It not only order issue, but also need to deal with receiver. And any partial soltion like `unthis` or `f@(...)` doesn't really solve the problem, still force people dramatically change the coding style. Actually underscore/lodash is the best example.

It's a misunderstanding that underscore/lodash is FP style, no they are not, and many FP professionals criticim them as "make the FP wrong". It's not wrong, but they are just not intend to FP. They are extention methods (almost all their functions are just move the receiver as the first argument), but because JS do not have extensions, the only way is to write them as utility functions. Underscore/lodash have a wrapper mode (like jQuery) in very early days, not used broadly (because wrapper has other problems), but wrapper mode could make the original intention much clear.

So this is why underscore/lodash not work well with F# style pipeline.

Yes you can use it with a Hack style pipeline, but it just because of general. Extensions make them work really as they tend to be.

The other side is real FP. And hack style actually worse on that. I don't want to describe how FP fans frustrate with Hack style, but I already said, it was not be blocked just because some delegates miss the meeting.

Another question is how hack style could be so general?

My option is it's because it's a mix of serveral things, pipeline op, and topic var, and some ability of escaping function boundary. But these features are not necessarily tied together. It could be a separte, more composable, orthogonal feature.

No time to write more...

---

Updates:

Some code examples to show the differences:

---
1. reuseable unit (method/util functions/unary curry fucntions)
1. OO method-style could cover Functional style
2.