> ...so only the first usage of `%` counts as a replacement?
Hopefully not because there’s no reason to: in the same way you can use + or - as prefix or infix, % as value and % as binary operator are not ambiguous.
% % %
should not be an issue, though it’s useless and not exactly sexy looking.
> I'm surprised they aren't going with an idiom like `$1`, `$2`, etc
That makes no sense, $1, $2, and $3 are different parameters.
Using your example,
|> `${$3.id}: ${$1.friendlyName} ${$2.url}`
makes absolutely no sense.
Not to mention the very minor issue that $1 is already a valid JS identifier.
> or something like in other languages that have "magic" lambda parameters.
% is one of those, it’s what closure uses for its lambda shorthand. Scalia uses `_` and kotlin uses `it`.
The latter two are ambiguous but I guess since pipes are new syntax there wouldn’t be a huge issue making them contextual keywords.
Most language with “pipelines” are curried so it’s not a concern, and in the rest it tends to be a fixed-form insertion, so it’s quite inflexible, but in both cases APIs are designed so they play well with that limitation e.g. in curried language you’d have the “data” item last (that’s obviously in Haskell), which also allows for partial application in general, while in “macro” languages, well, it depends where you decide the magical argument should be inserted (IIRC in Elixir it’s the first, so functions written for pipe compatibility should take the main operation subject first).
Clojure is cool because it has both plus a macro where you give it the name of the substituted symbol. However being a lisp the pipe macros are still prefix, not infix.
>That makes no sense, $1, $2, and $3 are different parameters.
>Using your example,
|> `${$3.id}: ${$1.friendlyName} ${$2.url}`
>makes absolutely no sense.
That's not what I was saying. I was saying that using `$1`, `$2`, and `$3` _would be different parameters, which would be good at helping disambiguate_.
That would enable this, from my example:
|> `${$1.id}: ${$1.friendlyName} ${$1.url}`
while also enabling something like this:
|> `$1.indexOf($2)`
...whereas just sticking with the single `%` means you _can't_ disambiguate, and that if they instead try to allow disambiguation by deciding that the first `%` is `$1`, and the second `%` is `$2` (and so on), then now you can't use the template-string example I gave.
Having unique "magic scope variables" at least allows you the flexibility to handle non-unary use-cases.
Either way, this is another case of "every lexer/parser has to be riddled with special cases" to handle "is this `%` a fancy-pipeline-identifier, or is it an operator?"
Enable for what? A pipeline threads a value through a sequence of operation, there is no second parameter.
> ...whereas just sticking with the single `%` means you _can't_ disambiguate
Which doesn't matter because there is nothing to disambiguate.
> Having unique "magic scope variables" at least allows you the flexibility to handle non-unary use-cases.
Which do not and can not exist.
And even if they did (which, again, they don't), you could do exactly what Clojure does with its lambda shorthand: %1, %2, %3, %4.
> Either way, this is another case of "every lexer/parser has to be riddled with special cases" to handle "is this `%` a fancy-pipeline-identifier, or is it an operator?"
There is no special case, having the same character be a unary and binary operator is a standard feature of pretty much every parser. Javascript certainly has multiple, as well as operators which are both pre and post-fix.
What if I need the value to be replaced multiple times, like this:
I'm surprised they aren't going with an idiom like `$1`, `$2`, etc or something like in other languages that have "magic" lambda parameters.