Proposal: Define pipe operator as function composition + define more syntax as functions

[atombender]

We can define the pipe operator as a function composition operator, where:

expr | f(args)

is syntactic sugar for:

f(args, expr)

This is exactly like the |> operator in Elixir, or the . operator in Haskell. For example, this:

* | count()

could be equivalent to:

count(*)

This explains why order can work as a pipe operator, since:

* | order(foo)

is simply:

order(foo, *)

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:

* | groupBy(_type) | summarize({"count": count(@))

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,

*[a == 1]{a}

could be equivalent to something like:

allDocuments() | filter(a == 1) | project(object(["a", a]))

which of course is the same as:

project(object(["a", a]), filter(a == 1, allDocuments()))

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.

[judofyr]

We can define the pipe operator as a function composition operator, where:

expr | f(args)

is syntactic sugar for:

f(args, expr)

My initial expectation was that it would be equivalent to f(expr, args), similar to how in Python foo.bar(baz) ends up calling bar(foo, baz). This would also make order() less strange as * | order(name) would become order(*, name). It also seems to be the way Elixir works:

https://elixirschool.com/en/lessons/basics/pipe-operator/

The pipe operator |> passes the result of an expression as the first parameter of another expression.

This is different from Haskell's . operator, but isn't that mostly because Haskell has the convention of "the data comes in the last parameter" (which we're not restricted by)?

As an aside, this opens up the opportunity to explain more of the GROQ syntax as being syntactic sugar for functions.

I love this idea.

allDocuments() | filter(a == 1) | project(object(["a", a]))

Tiny nitpick/comment: We should probably use pairs here: object("a" => a)

[atombender]

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 (map fn vals, not map vals fn), though of course that's the convention because it's super helpful for partial function application and currying.

Tiny nitpick/comment: We should probably use pairs here: object("a" => a)

Good point.

[atombender]

Tiny nitpick/comment: We should probably use pairs here: object("a" => a)

A pair "a" => a can be syntactic sugar for something like pair("a", a).