[erlang-questions] comma-less lists and tuples

Vlad Dumitrescu vladdu55@REDACTED
Thu Sep 21 11:46:43 CEST 2006


On 9/21/06, Ulf Wiger (TN/EAB) <ulf.wiger@REDACTED> wrote:
> Vlad Dumitrescu wrote:
> > To put it another way, putting an Erlang syntax around sql
> > statements (*) is just a way to make the programmer write
> > extra code in order to make things easier for the compiler.
> > Things should go the other way around, don't they?

Hi,

What I mean is that IMHO if one wants a structured representation of
something in textual form, the best way is to use a parser. As the
lazy programmer I am, I don't want to do manually do the parser's
work, while at the same time making the representation harder to read
and a nightmare to maintain...

> Do you mean teaching the compiler to parse SQL, or to leave
> it as is and letting the compiler remain ignorant? ;-)

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.

In the particular case of SQL, we can also skip any parsing and do
fine with strings - especially since sql is not only hard to parse,
but there are many different dialects too. I'd rather let the
database's parser take care of that.

I don't really see what's wrong with concatenating strings :-)
Escaping parts that come from outside needs to be done even with
quasi-sql. Using a parse transform as per my previous example would
make it even almost as readable as pure sql.

> This should then be a metric for evaluating any
> special syntax: do we actually gain something by forcing
> the programmer to write quasi-SQL rather than SQL directly?

Precisely. If it isn't obvious already, my opinion is that there is no
gain in completely erlang-izing the sql language. But that's just me.

best regards,
Vlad



More information about the erlang-questions mailing list