"sort sum_gross_cost # Uses the auto-generated column name." ... seems like a huge landmine. Languages really should not have any implicit way of constructing identifiers (among other reasons it is not easily greppable).
You might consider using a syntax like `sum:gross_cost` which can function as a sort parameter and an aggregation, but is actually recognizable as an object instead of having an implicit transformation going on in the background. Like this:
Yes, I agree with the downsides of the existing approach, and you're absolutely right re "Languages really should not have any implicit way of constructing identifiers".
I'd still say it's fine if it implicitly names output columns, for convenience.
The fact that someone felt the need to add that comment hints at a design mistake. Synthesizing symbols is weird, unnecessary and is probably a violation of the principle of least surprise.
Otherwise I think PRQL has some value. Nice work. I strongly suspect that if SQL looked more like this there would be a lot more people willing to use the query language directly and perhaps fewer that are compelled to bury it under shifting layers of fragile abstractions.
One piece of feedback:
"sort sum_gross_cost # Uses the auto-generated column name." ... seems like a huge landmine. Languages really should not have any implicit way of constructing identifiers (among other reasons it is not easily greppable).
You might consider using a syntax like `sum:gross_cost` which can function as a sort parameter and an aggregation, but is actually recognizable as an object instead of having an implicit transformation going on in the background. Like this:
Yes, I agree with the downsides of the existing approach, and you're absolutely right re "Languages really should not have any implicit way of constructing identifiers".
I'd still say it's fine if it implicitly names output columns, for convenience.
I referenced your comment in an issue and listed some options: https://github.com/max-sixty/prql/issues/5
> # Uses the auto-generated column name
The fact that someone felt the need to add that comment hints at a design mistake. Synthesizing symbols is weird, unnecessary and is probably a violation of the principle of least surprise.
Otherwise I think PRQL has some value. Nice work. I strongly suspect that if SQL looked more like this there would be a lot more people willing to use the query language directly and perhaps fewer that are compelled to bury it under shifting layers of fragile abstractions.