-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pipe operator support #146
Comments
I'm a fan. Although, I wouldn't describe Elixir's chaining syntax a solution for templating. For our use case I tend to lean towards:
But I'm just as happy with |
Sure 🙂 it's the same syntax (and the same semantics), it's just extra useful for our use-case when it comes to having single-line programs such as in string templates.
Yes, as I mentioned in my proposal, I also like that more, but it would preclude us from introducing bitwise or operations, I'm not really sure how useful that is to have in Remap, though? Maybe @bruceg has some examples that would be helped by having bitwise operators? (we can of course always add functions to provide this instead of having explicit grammar)
That's the example I gave, but it doesn't require a path as the lhs expression, it just requires any expression on the lhs, and a function expression on the rhs. The grammar would be something like:
I believe we have a very flexible and composable remap grammar. You should definitely take a look at our grammar.pest file, it's an easy read. We have a few more restrictions in the parser itself, but mostly this grammar file shows what's possible and what's not. most of the time, we take an expression as input wherever we can (in function arguments, if-statements, etc), given how the pipe operator works (e.g. passing in the lhs value as the first argument of the rhs function), we would have an exception in this case, and only allow function calls for the rhs value (with a clear error message to help people out). Other than that, 👍 on "formalize language design guidelines". |
I'm a fan too. My only hesitation for the use of |
Do we not use |
We do, but we only support path coalescing, and it requires the paths to be surrounded by parenthesis, so we're still free to use Having said that, I could still see us deciding against using
Agreed, there's no rush. It'll probably become more of a priority once we support TRL in template strings, but even then it's mostly to improve readability, not to unlock missing features, so there's no rush here. |
Remap revolves around expressions, most expressions are implemented as functions, which take zero or more input arguments, and provide output.
For example:
The above will eventually (#4905) also work in string templates in Vector itself:
The above works, but can be hard to read.
I wonder if we want to add support for the pipe operator (similar to Elixir).
The gist of this syntax would be that given an expression, if the expression is followed by the pipe operator (
|>
), then the expression after that operator would receive the result of the previous expression as its first argument.The precedence of the pipe operator would be higher than the other operators. This allows one to write:
You can still supply more arguments if need be:
This would be purely syntactic sugar to make the code easier to read, especially in string templates, but also in general.
There are still some design decisions to make (for example, what happens if you provide a non-function expression to the rhs of the pipe operator? Compile error?), but I wanted to put this issue up to gauge interest from others.
Also, some languages that focus specifically on templating use the
|
pipe syntax to do this:We could do this, but then we'd lose the ability to implement bitwise operators in the future.
cc @binarylogic @FungusHumungus
The text was updated successfully, but these errors were encountered: