[erlang-questions] comma-less lists and tuples

[Vlad Dumitrescu]

On 9/20/06, Yariv Sadan <yarivvv@REDACTED> wrote:
> I don't think Erlang's syntax should be extended to match arbitrary
> DSLs... however, I do think that allowing whitespace to be treated as
> a delimiter (if it's possible and it wouldn't break any existing code)
> would make the existing Erlang syntax, which is already quite friendly
> for a variety of DSLs (of which ErlSQL is just one example), even more
> DSL-friendly.

Yes, maybe. What I meant was that there may be other varieties of DSLs
that would benefit from other syntax changes. I agree the list/tuple
example was not realistic, but once starting on that path it's hard to
stop.

> > In this particuar case, I'd either go with full sql (it's at least
> > standard, people already know it) or find an Erlang equivalent that
> > isn't following sql that closely.
>
> The main benefit of ErlSQL is that it makes programmatic generation of
> queries in Erlang easy because you work with the semantic elements of
> SQL directly in Erlang rather than doing string concatenation.

Yes, I know, you are working with is the syntax tree of the sql
statements. Syntax trees need not (and in practice aren't) bear any
resemblance with the textual form of the original. I will argue that
it is even counterproductive - if the syntax tree form is meant to be
written by a human. Why write
    {select, [bob], {from, [person]}}
instead of
    select bob from person
?

If the tree form is just an internal form that only other programs
will manipulate, then the syntax of the data representing the tree
becomes irrelevant. Likewise the optimizations you started to
introduce (prefix operators).

 > The examples I've shown have a make a literal translation to SQL, which
> may not seem so impressive, but examples that involve more
> programmatic SQL generation look far better with ErlSQL than with
> string-concatenation.

Wonderful. The question is then: is it meaningful to change Erlang
syntax just so that a particular class of programs just _look far
better_?

If the goal is to make sql-building code more readable, there is
nothing that beats writing sql code, IMHO. The metaprogramming syntax
I am working on is still in the future (and is still a change to the
Erlang language), but even today you can do
something like

    Column = "bob",
    Table = "person",
    sql:statement("select $Column from $Table")

where sql:statement() would be processed by an adequate parse transform to

    ["select ",sql:escape(Column)," from ", sql:escape(Table)]

and if you need to, it could even parse it and return the syntax tree as above.

I may be biased because I don't work that much with sql, but to me it
is very readable and if I were a sql developer I wouldn't have to
learn a new way to express sql statements.

I hope I'm not sounding like I am putting you down, Yariv. I agree
very much with the idea behind ErlSql, it is just the form that
doesn't feel very comfortable to me.

regards,
Vlad