Proposition: supporting both options by making the Hack syntax a sugar syntax for unary functions about proposal-pipeline-operator HOT 5 CLOSED

In particular, note the arguments against this in the original Smart-Mix repo, which went to great effort to identify a useful subset of unary calling that could be mixed with topic expressions in a way that was easy to identify and difficult to get wrong.

Just doing a naive "if there's a topic token, do X, otherwise do Y" ends up having bad behavior for a couple of reasons, explained in the linked README.

from proposal-pipeline-operator.

Note that in @tabatkins response, it seems they have misunderstood the proposal made by OP.

This proposes adding a separate syntax for the definition of unary lambda functions using a topic token: %.foo defines topic => topic.foo.

And in combination with the F# pipeline operator that would approximate the Hack proposal: x |> %.foo -> x |> (topic => topic.foo) -> (topic => topic.foo)(x) -> x.foo.

So there is no "if the topic is there, do one thing, otherwise do another" like with the Smart-Mix proposal.

However, I do see other difficulties with the proposal. For example: [%.foo, %.bar]. Does that mean topic => [topic.foo, topic.bar], as it would with Hack? Or does it mean [topic => topic.foo, topic => topic.bar]? I'm not sure if a heuristic exists by which this question can be answered reliably and in a way that doesn't surprise developers.

from proposal-pipeline-operator.

A similar idea was suggested in #276. The conversation within has some references to other conversations about it.

from proposal-pipeline-operator.

This is an interesting idea. It'd be really compelling even outside of the pipeline context if we had named function parameters and named placeholders.

let fn = %a + %b.foo();
fn(a:4, b:x)

(I wasn't able to find the discussion that tabatkins was referring to in the Smart-Mix readme.)

from proposal-pipeline-operator.

Ah, yes, I did misunderstand. Rather, this is essentially asking for Partial Function Application, just with an even wider syntax.

This is unworkable as a solution for the same reasons that F# + PFA is (it encourages the creation of a ton of one-shot functions, it doesn't work with await, yield, and other function-scoped abilities we add in the future, etc), but has the additional issue that the syntax is extremely ambiguous. PFA goes to some decent lengths to ensure that function-calling, by itself, is unambiguous; if you extend it to more operators it quickly runs into ambiguous situations, as you illustrated.

I'm going to go ahead and close this, then, as it's answered by #221

from proposal-pipeline-operator.