Skip to content
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

into semantics as transform? #4291

Open
max-sixty opened this issue Mar 1, 2024 · 4 comments
Open

into semantics as transform? #4291

max-sixty opened this issue Mar 1, 2024 · 4 comments
Labels
language-design Changes to PRQL-the-language

Comments

@max-sixty
Copy link
Member

max-sixty commented Mar 1, 2024

Thanks to @broneill — full details at #4277 (reply in thread)

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
@max-sixty max-sixty changed the title 1 | into a failing into semantics as transform? Mar 1, 2024
@snth

This comment was marked as resolved.

@max-sixty

This comment was marked as resolved.

@aljazerzen aljazerzen added the language-design Changes to PRQL-the-language label Mar 8, 2024
@aljazerzen
Copy link
Member

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.

@max-sixty
Copy link
Member Author

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 into could return nothing, a bit like let foo = {let x = 5;} returns nothing in rust, and so let a get assigned null (not saying this is necessary or even good, just that it's not obviously a compiler error)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language-design Changes to PRQL-the-language
Projects
None yet
Development

No branches or pull requests

3 participants