Maximilian Roos

This is a good point. I don't think we should need it _that_ often — one of the benefits of PRQL should be to split up logic into modular pieces,...

Yes, interesting. So we could have a rule that finishing the line on an operator (e.g. `+` / `or` / etc) causes a line continuation. Are there any instances where...

> "Unexpected newline"? The challenge is that it wouldn't be parsed as a newline, it would be parsed as `derive bar = baz or aggregate (`, unless I'm misunderstanding something?...

> Cool! And to be clear, I'm just offering my random thoughts as a fan in the peanut gallery. Appreciate all the work you've already done! Thoughts generally welcome, and...

I really think this would be excellent. I agree it's for post-0.2 but +1 on opening the issue and adding things as we see them. I wrote in the PRQL...

Great, I agree with you on what would be required. Definitely agree re implicit conversions! I'm imagining the type experience as similar to writing rust _inside_ a function — the...

(@aljazerzen I labeled this "semantic", though lmk if "types" isn't actually part of that in your mental model)

Thanks for adding that @rslabbert . I very much agree with the "declaration files" — column names & types are slow-changing input that would benefit from an abstraction layer like...

+1! We could use something like https://dba.stackexchange.com/a/1958 for other DBs. We could represent this as a new transformation: ```elm from employees drop salary ``` Or a named arg to `select`...

As discussed on discord: > I think we could do this, and then just fail if we don't know the column names (unless it's a dialect, like BigQuery, which supports...