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
Piping syntax #612
Comments
I think @hausdorff proposed the same thing before, even with the same syntax |
Yeah, I think it was pretty much the same thing. From what I remember the approach to partial application was different (from what I remember it was something like one more argument was implicitly passed, and it couldn't be used without "piping"). I can't find the issue or anything, though (did the discussion take place only on Slack?). |
I think that it's better to have just the "forward piping" version (it's better not to provide two competing ways of doing the same thing). I don't see any case where backward piping (a'la Haskell's |
Hmmm... actually backward piping could be useful for things like |
Would that imply object keys like |
First, this was just about locals. Object fields are a completely different story. They don't even have to be valid identifiers. It may still be to strong. One concrete thing I was I was thinking about was having something like _1, _2 meaning first, second argument etc. |
Any updates on this? I've found myself wanting this syntax quite a lot. Furthermore, I think there's a detail that could make it even nicer: having the Let's say the local pipe(input, f) = if f == null then input else f(input); Why would that be nice? Consider this: input
|> if config.capitalize then capitalize(_)
|> if config.revert then revert(_)
... I often find myself conditionally applying functions; without this, you'd still need to branch out and use temporary variables to share a common "prefix" of a pipeline. In the above case, you'd need to do something like this: local a = if config.capitalize then capitalize(input) else input;
local b = if config.revert then revert(a) else a;
... |
Yeah, having This feature is not strictly required for this flow. You can have:
|
And there has been no progress. If someone wants to pick it up, it would be a very welcome addition. I'll be happy to help in case of any questions. |
google/jsonnet#612 Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
Implemented feature as described in this thread in jrsonnet (in branch, not in release), but without
limitation, as I'm probably not sure, why this limitation is needed. Please point out if I misunderstood proposed semantics :D I think the proposed semantics is quite vague, I do not like that both If anyone wants to try, jrsonnet with this feature can be installed using |
To avoid ambiguity when nesting. How do you know if Also, the implementation could be simpler, depending on internal representations. Generally, I think it's better to err on the side of minimalism in these things – adding is much easier than removing. |
My suggestion was that Then |
Aha! Makes sense. In this case, something is certainly needed for multiple arguments. My current implementation only has special handling for |
I don't think there is any rush, I just wanted to get this idea out of my head.
The proposal has two parts:
a |> b = b(a) // forward piping
a <| b = a(b) // backward piping
The arrow points in which direction the value flows. The forward piping allows programming in UNIX-pipes style - allows cleanly doing multi-step processing without defining too many helper functions.
Backward piping is going to be useful with more "functional style" programs - it allows avoiding some parentheses (pretty much like Haskell's
$
).I'll start with an example:
So the idea is that instead of an argument
_
can be "passed" - a hole where a value can be put. The_
is interpreted this way only when it is passed as an argument. No complex expressions involving it are allowed.f(2 + _)
is not allowed.So
f(a, b, c, _, d) = function(x) f(a, b, c, x, d)
.It's unambiguous which expression is wrapped in a function - it's always just the function application.
It would be possible to also do things like this:
The issue is that
_
is a valid identifier. It's unfortunate. We can either find a new symbol or interpret it this way only when there is no local variable named that. This can be handled during desugaring, though it's going to be quite annoying. We should also discourage using_
(or anything starting with_
for future proofing) if we go with that - possibly using Linter.The text was updated successfully, but these errors were encountered: