Feature PF: Pipeline functions need to be variadic even without Feature NP about proposal-smart-pipelines HOT 4 CLOSED

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.

from proposal-smart-pipelines.

@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…

from proposal-smart-pipelines.

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.

from proposal-smart-pipelines.

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.

from proposal-smart-pipelines.