Function syntax and the pipe operator about prql HOT 5 CLOSED

Hi @SilverEzhik — thanks a lot for the full and thoughtful issue

I'll answer as much as I can now and please let me know if I miss anything:

• Definitely this takes inspiration from the ML world. So the pipe is one way of calling a function. Specifically, these three are equivalent:

  # 1.
  x | lag_day
  
  # 2.
  lag_day x
  
  # 3.
  (
    x
    lag_day
  )

• The use of is_valid_price bugs me a lot as it's not actually in scope of the function. What would happen if it was called on a table that didn't have that column?

  Good question. You can think of a column name like is_valid_price as either an identifier than needs to be in scope, or a constant. The existing code works if it's considered a constant which doesn't require scope. If it's required to be in scope, it would make functions much less useful — every column name would need to be passed into every function, IIUC. And in PRQL, column names are just strings to us, they're not representing anything more abstract that we need to bind to. Can you think of a case where the current approach would cause any ambiguity in the transpilation?

• FWIW at least in OCaml, x | foo(a, b, c) is equivalent to foo(a, b, c, x) (note the different in location of the x from above):

  # let f x y = (x * 10) + y;;
  val f : int -> int -> int = <fun>
  # let g = 1 |> f;;  (* g now equals (10 + y), because 1  binds to the first arg *)
  val g : int -> int = <fun>
  # 2 |> g ;;
  - : int = 12

  So that's the current design of PRQL; first bullet here

• I agree re the issues with boolean logic and infix operators. I discuss some of the tradeoffs in "Thinking about". I'm open to ideas and approaches there.

• I tend to agree re the ternary operator. We need to figure out how we transpile to SQL's if ... then and case so we have a single approach and uses common keywords in a consistent way.

• I agree with your views on single vs double quotes, and the raw sql tradeoffs. Backticks are good. One issue is that they conflict with markdown — someone copies a line into a markdown file and then needs to escape it, and f-strings have been really successful. So that's another area we can think about and iterate on.

We can open issues on any of the final three items if people would like to discuss them.

Thanks @SilverEzhik

from prql.

@max-sixty

Can you think of a case where the current approach would cause any ambiguity in the transpilation?

If PRQL functions are mapped to SQL functions, wouldn't scope become a problem? Or is the plan to have these functions essentially be macros that get substituted into the translated SQL?

One potential fix would be to require scoping functions inside the query:

from some_table
func foo x = ...     # foo has access to columns of some_table
join other_table ... # but not to columns of other_table

Thinking about it, this probably doesn't matter if PRQL is just getting compiled into SQL, but if it was aware of the table schema, this could be used to catch errors before the query gets translated.

from prql.

Probably a silly question , but for the pipe syntax of x | some_func , how do you pass two parameters to the function, x,y | some_func ?

but if it was aware of the table schema, this could be used to catch errors before the query gets translated.

Oh man, that would be amazing.

from prql.

how do you pass two parameters to the function, x,y | some_func ?

Piping can only pass one arg, so that would be y | some_func x or some_func x y.

but if it was aware of the table schema, this could be used to catch errors before the query gets translated.

I'll try and write something up on this around a roadmap — it seems like there's lots of excitement around it. It's much much harder than the current plan, but would follow on nicely, assuming we can execute on the current plan.

from prql.

I think these have been answered or covered elsewhere. It was an excellent set of issues!

Please keep them coming @SilverEzhik & @qorrect .

from prql.