Feature PF: Pipeline functions need to be variadic even without Feature NP

[js-choi]

The current draft’s Feature PF uses +> to create unary-parameter functions. This means that arguments after the first argument are discarded. This may result in surprising behavior, especially given that +> is intended to address method extraction. For instance, (+> console.log)(5, 2) is equivalent to ($ => $ |> console.log)(5, 2), which prints only 5. This is not equivalent to console.log.bind(console), contrary to what the explainer currently says. In addition, this makes Feature PF without Feature NP incompatible with adding Feature NP in the future.

The spec needs to be changed so that Feature PF creates variadic functions that apply all their arguments to the first. +> console.log would instead be equivalent to (...$) => console.log(...$), and (+> console.log)(5, 2) would correctly print 5 and 2.

Much of the work is already done, because even the Core Proposal allows for multiple topics. Feature PP would also need to be changed such that, if a pipeline’s lexical environment has multiple topics, then all of them are applied to the pipeline’s body.

[tabatkins]

Does this mean that PF requires NP in its entirety? Or just that it's implicitly variadic for the first pipeline, and afterwards is unary (unless NP is accepted)?

If the latter, I see how this would work with bare-form, but it seems like we would we have to accept NP's syntax additions to make it work with topic-form.

[js-choi]

@tabatkins: Good question. No, PF does not require NP. NP is only the notation for applying N-ary arguments to expressions/functions specifically using |> with an ArgumentList (such as in (1, 2) |> f). I will clarify this in the explainer, too.

PF does not require that notation. In fact, the core proposal already defines topic bindings as a list per declarative environment record, for this very reason. During its runtime evaluation , the |> operator in the core proposal creates lists of only one element out of its head expression—but its other runtime semantics already accommodate multiple arguments even in the core proposal.

I’ve been wondering if I should update the examples in slide 17 of @littledan’s London TC39 presentation so that +> f |> g is more correctly (...$) => g(f(...$)), rather than $ => g(f($))…but there’s not much room in those slides…

[js-choi]

Also, without Additional Feature NP, variadic parameters only apply to bare-style pipeline functions, not topic-style pipeline functions. Without Additional Feature NP, topic-style pipeline functions could use only one parameter anyway. So the fact that lexical environments already bind lists of topics doesn’t even matter. What matters is that the PipelineBodyEvaluation runtime semantic rule already does accommodate lists of topics.

I updated the examples London TC39 presentation, slide 17 in light of this issue.

[js-choi]

Additional Feature PP (prefix |>) also needs to be tweaked to accommodate Feature PF even without Feature NP, in order to preserve both its forward compatibility with Feature NP and the invariant rule that +> |> something always cancels out into +> something. Each of the following code blocks’ lines are mutually equivalent.

// Starting with unary topic style.
+> [#] |> f |> # + 1;
($) => $ |> [#] |> f |> # + 1;
+> |> [#] |> f |> # + 1;
($) => $ |> # |> [#] |> f |> # + 1;

// Starting with unary topic style.
+> [#, ##];
($, $$) => ($, $$) |> [#, ##] |> f |> # + 1;
+> |> [#, ##];
($, $$) => ($, $$) |> (#, ##) |> [#, ##] |> f |> # + 1;

// Starting with variadic topic style (1 positional topic).
+> [#, ...];
($, ...$rest) => ($, ...$rest) |> [#, ...] |> f |> # + 1;
+> |> [#, ...];
($, ...$rest) => ($, ...$rest) |> (#, ...) |> [#, ...] |> f |> # + 1;

// Starting with variadic bare style.
+> f;
(...$rest) => ...$rest  |> f |> # + 1;
+> |> f;
(...$rest) => ...$rest |> ...  |> f |> # + 1;

In other words, even without Feature NP, prefix |> needs to use some of the same infrastructure that Feature NP uses, to determine whether the arity of a pipeline is unary or variadic. This infrastructure may be moved from Feature NP to Core Proposal, in order to distinguish +> |> f (variadic) from +> |> # + 1 (unary). From the developer’s point of view, without Feature NP, this only affects pipeline functions that start with bare-style prefix |> pipelines, like +> |> f, and nothing else.

Should be easy to do.