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.
So the same thing except more verbose.
> while also enabling something like this:
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.