-
Notifications
You must be signed in to change notification settings - Fork 13
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
Proposal: Define pipe operator as function composition + define more syntax as functions #41
Comments
My initial expectation was that it would be equivalent to
This is different from Haskell's
I love this idea.
Tiny nitpick/comment: We should probably use pairs here: |
Yes, the order isn't the most important thing, and we could switch it around. I didn't realize Elixir was different, I just skimmed something mentioning the operator. I always thought it annoying that in Haskell you end up with the function first (
Good point. |
A pair |
We can define the pipe operator as a function composition operator, where:
is syntactic sugar for:
This is exactly like the
|>
operator in Elixir, or the.
operator in Haskell. For example, this:could be equivalent to:
This explains why
order
can work as a pipe operator, since:is simply:
Of course, right now
order
takes multiple arguments, which will require supporting "leading varargs", but it's not too bad.Similarly, we can invent new functions for richer data manipulation, such as:
and so on.
As an aside, this opens up the opportunity to explain more of the GROQ syntax as being syntactic sugar for functions. For example,
could be equivalent to something like:
which of course is the same as:
In other words, this "reformulates" GROQ as a simpler "canonical form", with the syntactic sugar as a layer of conveniences on top of a rich set of pipeline-oriented function calls.
While the practical benefit of doing this, from a user’s perspective, is probably limited, it has an explanatory benefit.
The text was updated successfully, but these errors were encountered: