Hacker News Reader

Comment by masklinn | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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.)

> 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.

Aside: I avoid ORM hell by using SQL to generate source code.

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.

We can simply employ ACI (automatic comma insertion). Every newline after Select implies a comma, unless there’s a clearly unfinished column definition. And if you want to list columns on a single line, you have to type commas explicitly.

  Select Foo Foo, Bar +
    1 Baz
    Baz Bar
    Quux Frob
  from
    t Table

Actually it's still ambiguous, because you forgot about sub-expressions. How would you parse this:

   SELECT a as aliasA b select q from foo as aliasQ c as aliasC FROM d as aliasD e

Even if you can figure it out (and add a 3rd level of sub-expression before deciding if you can), it's completely unreadable. You need either commas or parenthesis.

You can get either commas or required `as` and parenthesis around expressions.

IMO, required `as` and parenthesis are better. But it's not a clear thing where everybody will agree.

Ideally there'd be a syntax that looked like a function `SELECT(a, b, c, d)` with a totally distinct variant for specifying types `TSELECT(a, int, b, null, c, text, d, timezonetz)`.

The big problem here is the seemed-good-in-the-70s syntax that died with SQL. In the best of all possible worlds they could have just used Lisp as the foundation then let people macro/transpile their own syntaxes. A subtle flaw in SQL is being just hard enough to correctly emit that most people don't build new languages on top of it.

Oh, just add optional commas at the end of your language's parameter lists...

I have really no idea what's "ideal". Haskell's "white space means application" is way nicer than most function syntaxes, end of line statement separation work very well if you don't need any long statement, the SQL complex syntax is very convenient... and yet if you mix any of those things, you'll get a truckload of disastrous issues.

But one thing that is clear is that allowing for trailing commas in SQL is a gain.

There is PRQL and a few others. There is also JOOQ which does transpilation to and between various SQL dialects (sadly open core with a small core). Also, some databases like ClickHouse are implementing alternative languages like PRQL and Kusto natively.

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.

> I'd still want to have leading commas.

Real happy for you. Trailing commas support don’t prevent you from doing that.

Reply on news.ycombinator.com