8 ms·

That is the haskell workaround, and it also sucks, because it still requires a special non-uniform first value. I do not want to write either of your snippets,

That is the haskell workaround, and it also sucks, because it still requires a special non-uniform first value. I do not want to write either of your snippets, I want to write SELECT a, b, c, FROM Because now selected values are uniform and I can move them around or add new ones with minimal changes no matter their position in the sequence. It’s also completely wonky in many contexts e.g. CREATE TABLE. Trailing commas always works. > I'd suggest to maybe just change your coding style - and make the start of the list special - instead of the end. Supporting trailing commas means neither is special.

adornKey 2y ago
I'd still want to have leading commas. If the items in the list are long IF(...), maybe uses several lines and maybe contain SELECTs it's hard to see a missing trailing comma. At the start they're all lined up well, and it's very hard to get them wrong.
- masklinn 2y ago
  > I'd still want to have leading commas. Real happy for you. Trailing commas support don’t prevent you from doing that.
catapart 2y ago
Spot on. Also, to generalize a bit: if a human is expected to read it, the way humans write should be able to be parsed by it. That's subjective, to a point, but it's an easy rule-of-thumb to remember. Trailing commas are so common that people have built workarounds for them. Therefore, they can be understood as "the way humans write". If you're writing a language that you still want to be readable by humans, you really should account for that. And, no shade for it not already being done. I'm just reiterating that there should be NO pushback to allowing trailing commas. It's a completely "common-sense" proposal.
- roenxi 2y ago
  > It's a completely "common-sense" proposal. The SQL standards committee is having none of it. I can tell you that just from this one sentence. And, more seriously, there isn't really such a thing as a common-sense proposal with SQL. The grammar is so warped after all these years that there isn't a path to consistency and the broken attempt at English syntax has rendered it nearly incomprehensible for both human and machine parsing. Any change to anything could have bizarre flow on effects. I'd love to see trailing commas added to SELECT though. Given the mess it isn't possible to make the situation worse and the end of the list being special can be infuriating.
yellowapple 2y ago
I don't want to write commas at all. I want to write SELECT a b c FROM d Or even SELECT a b c FROM d Because now selected values are uniform and there's no superfluous punctuation to worry about.
- specialist 2y ago
  This would work (w/ a context free grammar) if aliases required the 'AS' keyword. Ambigious: SELECT a aliasA b c aliasC FROM d aliasD e Unambigious: SELECT a as aliasA b c as aliasC FROM d as aliasD e Alternately, a schema-aware parser could determine if 'aliasA' was an alias or a column reference. FWIW, personally, I'd rather go the full-Python, using newlines as delimiters: SELECT a aliasA b c aliasC FROM d aliasD e (With tabs for nesting.)
  - rollcat 2y ago
    > FWIW, personally, I'd rather go the full-Python, using newlines as delimiters: I love Python - mostly, but significant whitespace is its worst curse, and I'd love new languages to move away from the idea. I enjoy Rust because I can write out garbage faster than I can think of it, and the auto-formatter will make it look neat. Also, have you experienced the unspeakable horror that is templating YAML files? Of course in SQL prepared statements is the safe&sane way to go, but there are cases where you still have to generate SQL as text, such as when building an ORM.
    - specialist 2y ago
      Aside: I avoid ORM hell by using SQL to generate source code.
      - rollcat 2y ago
        I'm slowly shifting in that direction as well, but the libraries built around this style are far less mature / mainstream. Django is the "boring" solution and gets hella work done.

adornKey 2y ago

I'd still want to have leading commas. If the items in the list are long IF(...), maybe uses several lines and maybe contain SELECTs it's hard to see a missing trailing comma. At the start they're all lined up well, and it's very hard to get them wrong.

masklinn 2y ago
> I'd still want to have leading commas. Real happy for you. Trailing commas support don’t prevent you from doing that.

catapart 2y ago

Spot on. Also, to generalize a bit: if a human is expected to read it, the way humans write should be able to be parsed by it. That's subjective, to a point, but it's an easy rule-of-thumb to remember. Trailing commas are so common that people have built workarounds for them. Therefore, they can be understood as "the way humans write". If you're writing a language that you still want to be readable by humans, you really should account for that. And, no shade for it not already being done. I'm just reiterating that there should be NO pushback to allowing trailing commas. It's a completely "common-sense" proposal.

roenxi 2y ago
> It's a completely "common-sense" proposal. The SQL standards committee is having none of it. I can tell you that just from this one sentence. And, more seriously, there isn't really such a thing as a common-sense proposal with SQL. The grammar is so warped after all these years that there isn't a path to consistency and the broken attempt at English syntax has rendered it nearly incomprehensible for both human and machine parsing. Any change to anything could have bizarre flow on effects. I'd love to see trailing commas added to SELECT though. Given the mess it isn't possible to make the situation worse and the end of the list being special can be infuriating.

yellowapple 2y ago

I don't want to write commas at all. I want to write SELECT a b c FROM d Or even SELECT a b c FROM d Because now selected values are uniform and there's no superfluous punctuation to worry about.

specialist 2y ago
This would work (w/ a context free grammar) if aliases required the 'AS' keyword. Ambigious: SELECT a aliasA b c aliasC FROM d aliasD e Unambigious: SELECT a as aliasA b c as aliasC FROM d as aliasD e Alternately, a schema-aware parser could determine if 'aliasA' was an alias or a column reference. FWIW, personally, I'd rather go the full-Python, using newlines as delimiters: SELECT a aliasA b c aliasC FROM d aliasD e (With tabs for nesting.)
- rollcat 2y ago
  > FWIW, personally, I'd rather go the full-Python, using newlines as delimiters: I love Python - mostly, but significant whitespace is its worst curse, and I'd love new languages to move away from the idea. I enjoy Rust because I can write out garbage faster than I can think of it, and the auto-formatter will make it look neat. Also, have you experienced the unspeakable horror that is templating YAML files? Of course in SQL prepared statements is the safe&sane way to go, but there are cases where you still have to generate SQL as text, such as when building an ORM.
  - specialist 2y ago
    Aside: I avoid ORM hell by using SQL to generate source code.
    - rollcat 2y ago
      I'm slowly shifting in that direction as well, but the libraries built around this style are far less mature / mainstream. Django is the "boring" solution and gets hella work done.