prql
prql copied to clipboard
`into` semantics as transform?
Thanks to @broneill — full details at https://github.com/PRQL/prql/discussions/4277#discussioncomment-8648606
I had been thinking of into as a transform — so following a pipe (either a | or new line).
Currently, quoting from the discussion linked above
valid, correctly so
from y
into x
from x
valid, but incorrectly so — I think should be invalid
from y into x # should require `|`
from x
invalid, but incorrectly so — I think should be valid
from y | into x # the `|` should make it valid
from x
Can you give an example of how 1 into a is legal? I tried to produce one myself but couldn't get it to work.
Can you give an example of how
1 into ais legal? I tried to produce one myself but couldn't get it to work.
[edited]
A better example is:
from y into x
from x
Will edit the original and hide these, thanks a lot @snth
Discussion for adding into is here: #2427
#2427 mentions benefit of scanning only the first keyword in the line to find all variable declarations, which would be against this.
I'm not sold on making into a normal function, because we want into to be a special keyword, because it cannot be used somewhere in the middle of a pipeline (or a function call tree):
let a = (
from x
into b
)
This feels very wrong.
To get the proposed results, we could just add additional syntax that would allow top-level expression to have | into x appended so that would count as variable declaration.
I would be -0 on this compromise.
It feels like the best solution here would be to just provide good errors when the into keyword is used where it shouldn't be.
My main point here is that saying "within a pipeline, a pipe character is the same as a newline — except in the case of into" seems complicated, and we get a much simpler result by avoiding that exception.
Ref these docs:
In almost all situations, a line break acts as a pipe. [though we go on:] But there are a few exceptions where a line break doesn’t create a pipeline:
A level down:
let a = ( from x into b )This feels very wrong.
Yes fair! Though:
- this could be an error because there's no value being assigned to
a - or even
intocould return nothing, a bit likelet foo = {let x = 5;}returns nothing in rust, and solet aget assignednull(not saying this is necessary or even good, just that it's not obviously a compiler error)