> Did you consider using a keyword like `let` for column declarations
Yeah, the current design for that is not nice. Good point re the keyword scanning. I actually listed `let` as an option in the notes section. Kusto uses `extend`; dplyr uses `mutate`; pandas uses `assign`.
I opened an issue here: https://github.com/max-sixty/prql/issues/2
Another suggestion around `let`: consider splitting it into two operations, for creating a new column and for modifying an existing one. E.g. called `let` and `set`. Those are in effect pretty different operations: you need to know which one is happening to know how many columns the table will have, and renaming a table column can with your current system change which operation is happening.
Splitting them into separate operations would make things easier on the reader: they can tell what's happening without having to know all the column names of the table. And it shouldn't really be harder for the writer, who ought to already know which they're doing.
I encountered something like this at my previous job. We had a DSL with an operation that could either create or modify a value. This made the code harder to read, because you had to have extra state in your head to know what the code was doing. When I rewrote the DSL (the rewrite was sorely needed for other reasons), I split the operation in two. I was worried people would have been too used to the old language, but in practice everyone was happy with it.
This could _mostly_ be enforced by PRQL. There's a case where we transpile to:
select *, x+1 as x_plus_one
I opened an issue here: https://github.com/max-sixty/prql/issues/6
Couldn’t we just not allow modifying an existing column? Ie. we would not allow
count = count + 1
new_count = count + 1