| 00:03 | <TabAtkins> | Still angling for ## too. |
| 00:03 | <TabAtkins> | But yeah, we should def put the question to the committee this next meeting and just stick with the results. |
| 02:46 | <rkirsling> | I'm not seeing * on https://github.com/tc39/proposal-pipeline-operator/wiki/Bikeshedding-the-Hack-topic-token/ |
| 02:48 | <rkirsling> | but it's hard to believe that this wouldn't've been discussed -- is it precluded by something? |
| 02:56 | <ljharb> | multiplication and exponentiation of pipeline placeholder values seems like it’d be pretty common |
| 03:28 | <rkirsling> | ah right. I really dislike the idea of using |> for anything other than denesting function call parens but that's indeed a problem |
| 03:28 | <rkirsling> | however, it's also a problem for %. we should add that rationale to the chart |
| 03:31 | <rkirsling> | oh I guess it's technically there for %: "Most pipe expressions would not contain the remainder operator %." |
| 03:31 | <rkirsling> | "how common a binary operator is in practice" feels like a deeply flimsy argument, but avoiding binop tokens is a valid stance to take |
| 06:57 | <ljharb> | i think it's pretty well supported by usage; the airbnb config bans bitwise operators entirely (re ^) and % is pretty rare too |
| 18:22 | <pokute> | ah right. I really dislike the idea of using complexExpression |> { input: #, modifier: 'foo' }; |
| 20:29 | <rbuckton> | Does this include packing into an object too: await/yield better than F#-style. Using it for other operations feels like it will obfuscate the meaning of your code more than it will help. |
| 20:35 | <rbuckton> | Chaining multiple function calls using a single context is fairly common practice. For something like a math operation, it's more common to name variables as often those names have meaning in various algorithms and make them easier to recognize. |
| 20:41 | <rbuckton> | If I were to change the PFA placeholder to a different token, how much traction would `?` have as the topic? I've been considering swapping the placeholder to `~` to match the proposed `f~()` syntax. |
| 20:42 | <rbuckton> | Plus, I'm feeling less and less confident PFA will ever advance. |
| 21:11 | <pokute> | I guess it depends on what one considers functions then. I could consider anything that (optionally) takes input and returns output to be function of sorts (side effects are a different matter though). Formal JS functions are a convenient, and often the only feasible way to encapsulate such data transformation operations in a way that they can be called again and modified etc. The expression side of 1 |> # + 2 does not implement anything that's included in Function.prototype so it's not a Function, but is could be seen as a broader-sense function. |
| 21:28 | <pokute> | Don't mind too much about that and focus on having PFA advance. I really liked the introduction of f~() syntax after getting stuck and it was an excellent move as a champion that narrowed down the opposition against the proposal. It might be that the problem space that PFAs help solve are a bit too ambiguous currently and other dataflow proposals getting into standard / getting stalled can help find its niche. I can see you've done a great job with the proposal and I'm really grateful for you championing PFA. Even if PFA doesn't advance, having it in the history where it was honestly evaluated is a good signal. |
| 21:58 | <pokute> | I don't think the discussion of the current JS dataflow would be up to this point without the sincere effort put into PFA as one alternative part of the solution. |