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.

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.

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

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.