Syntax for aggregation with multiple arguments about prql HOT 7 CLOSED

IIRC the piped arg goes first in Elixir

https://elixirschool.com/en/lessons/basics/pipe_operator

from prql.

Yes, I think that's ideal, thanks @RCHowell

I would tend to have the settings of the function be first, and the column arg last, because pipes put their input last, so the most flexible arguments should go last, e.g. salary | pct 0.5. And if we allowed partial functions, this would be compatible; i.e. func median = pct 0.5).

If you want to have a go at a few example functions, they could go into examples!

from prql.

What about a placeholder, because some aggregations can take multiple identifier expressions such as corr col_1, col_2?

Also, "settings" of the function typically goes after the "core" arguments in the case of function overloading. A simple example would be foo.indexOf(bar) and foo.indexOf(bar, offset) ie default parameters via overloading.

from prql.

Ah, so in R, the piped argument goes first:

• x %>% f(y) is equivalent to f(x, y)

Are there other languages which work that way? Here's an example of OCaml approach, where they go last: https://github.com/max-sixty/prql/issues/11#issuecomment-1021911352

For optional args, then the order doesn't matter, so that would be bar | indexOf offset:1 with either of the options...

from prql.

Nice find @RCHowell .

So we have pipes putting the arg

• Last: OCaml + F#
• First: R + Elixir

Julia has implementation that do each (e.g. Chain.jl vs DataPipes.jl)!

An advantage of putting it last is that partials work (func median = pct 0.5), and it makes more sense to me that the settings of a function bind more tightly than what the function runs on.

But I don't have a super-confident view, so whatever the consensus is I'm happy with.

from prql.

Here's a discussion of Clojure's approach, which has a pipe symbol for each type (!): https://clojure.org/guides/threading_macros

from prql.

Closing — we went ahead with the Ocaml & F# approach. Not completely immutable; we can see how we go.

from prql.