[erlang-questions] comma-less lists and tuples

[Richard A. O'Keefe]

"Yariv Sadan" <yarivvv@REDACTED> wrote:
	When working with ErlSQL, I came to the opinion that in some
	cases, Erlang would benefit from allowing whitespace as a
	delimiter in lists and tuples in place of commas.
	Consider this small example:
	
	{select, [foo, bar, baz], {from, [table1, table2]}, {where,
	{xyz, '=', {'+', [1,2,3,4]}}}}

The thing that strikes *me* most forcibly about that is the
quantity of noise words.  Coding something like this in Prolog,
I would use

    select(Selection, Source[, Restriction[, Grouping]])

e.g.

    select([foo,bar,baz],
           table1 * table2,
           xyz = 1+2+3+4)

and this would work rather nicely because Prolog predicate arguments
are not (except in some very exceptional cases) evaluated (and even
then, they are notionally evaluated by the callER, not the callEE).

I note that in SQL 92, the "from" part is not a simple list of tables,
but an expression, so I would be inclined to write

    {select,
      [foo,bar,baz],
      {cross,table1,table2},
      {=,xyz,{'+',1,2,3,4}}}

where the general form for an expression is
    expression ::= number
                |  string
		|  atom
		|  '{' operator {',' expression}* '}'

    operator ::= atom

and we have

'{' 'select' ','
    list(expression),
    expression
    [',' expression			% where
    [',' list(expression)		% group by
    [',' expression			% having
    ]]] '}'


	If commas were optional, this example could be written as

	{select [foo, bar, baz] {from [table1, table2]}
	{where {xyz '=' {'+' [1 2 3 4]}}}}

	I think the second line is more readable, and it's also easier
	to write.

Erlang syntax owes much to Strand88 (whatever happened to Strand88,
anyway?) and Prolog.  Prolog has user-defined operators, so this could
not work in Prolog.  Erlang doesn't have user-defined operators, but
they would often be nice, and other functional languages like Haskell,
Clean, SML, and CAML have them.  It would be sad to adopt a feature
which made user-defined operators unusable now and forever.

One obvious question is whether the Lispy form (don't get me wrong,
Lispy syntax is GREAT, but you have to be consistent about it, and
Lisp, of course, _is_) is easier to write *correctly*.  Maybe it is,
but it _looks_ error-prone.  

	In other DSELs, the difference may be even more
	substantial.
	
We can confidently expect each new DSEL to stress *some* aspect of
Erlang syntax; we *can't* expect them to all stress the *same* aspect.
In particular, I would dumbfounded if there were no DSELs for which
user-defined operators and unevaluated expressions were not extremely
convenient.  Come to think of it, SQL is one of them.

By *far* the most readable and writable way to write SQL queries
in Erlang would be something like

    @sql[ select foo, bar, baz
	  from table1, table1
	  where xyz = 1+2+3+4   ]

where
    '@' <identifier> <left bracket>
    <bracket-balanced token sequence>
    <right bracket>

<left/right bracket> ::= (/) | [/] | {/} | <</>>

would take a sequence of tokens and pass it off to
    <identifier>_parser:parse(Tokens)
    
Within the bracket-balanced token sequence,

    '@' '=' <Erlang primary>

would let you embed Erlang expressions (which would be passed as
some kind of token).

Hmm.  Wait.  Let's add a new declaration

    -embedded_syntax(<syntax identifier> , <parser module name>).

to go near the top of a file, so you'd have

    -embedded_syntax(sql, my_sql_parser).

and then you could have

    Query = @sql{ select foo, bar, ugh from @=Table1, @=Table2
                  where xyz = @=XYZ }


	What do you think? Am I missing something?
	
Generality.