[erlang-questions] comma-less lists and tuples

[Ulf Wiger (TN/EAB)]

Vlad Dumitrescu wrote:
> 
> How could the Erlang compiler help me write better SQL
> statements? Yes, if I write quasi-SQL, I get some syntax
> checking, but I still can write stupid things like
>     {select, {where, {x, '=', 3}}, foo, {from, [table]}} 
> which is a correct Erlang term, but not correct quasi-SQL.

Well, that would be the task of a domain-specific parser,
or a parse_transform.

Basically:

- pure SQL in a string or binary
  + nothing can be decided at compile time, except perhaps 
    that it is a string or a binary.

- a record or list of atoms etc. mimicking SQL
  + syntactic checks can be made at compile time, but no
    semantic checks, like the one you describe

- a very regular structure with a library doing lots of 
  pattern matching
  + dialyzer can possibly, at "compile time", determine
    that your statement will not pass the pattern matching
    of the library, since it's not properly structured.

- a domain-specific parser
  (either as ROK suggests, or perhaps by wrapping the 
   query inside a pseudo function and checking it in a
   parse transform, much like with QLC and Mnemosyne)
  + extensive checks and optimizations can be made at
    compile-time.

With the last option, one has to decide whether to stick
to regular Erlang syntax, or depart from it. It doesn't 
preclude using plain SQL syntax, since you can call an
SQL parser from the parse transform. If you want a yecc
grammar for SQL, there is one, actually, which works 
at least for a significant subset of ANSI92 SQL.

Departing from Erlang syntax is tricky in a parse transform,
since the erlang tokenizer and parser will get hold of it 
before your parse transform. Using erlang syntax, but 
imposing your own semantics is likely to confuse the 
reader. I did that to some extent in plain_fsm, by wrapping
a receive statement inside a pseudo function in order 
to handle OTP system messages. The obvious dilemma was
that pattern matching can't be extended that way, so
the parse transform had to turn it into something quite
different. This has to be clearly explained, and the 
sought advantage is partly spoiled.

What would be very nice, I think, would be to write a 
QLC generator for e.g. MySQL. Nice - if someone else
decides to do it, and I wouldn't have to. (:

A MSc student did write an SQL parser converting SQL
to Mnemosyne queries. This worked quite well. Going
from a QLC query to SQL should be doable, and - assuming
I'm right - raises the argument that Erlang already 
_has_ quite a powerful syntax for database queries.
So why invent a new one?

BR,
Ulf W