[erlang-questions] comma-less lists and tuples

[Yariv Sadan]

(Vlad, sorry for sending this twice -- I forgot to CC the list)

> Yes, naive string concatenation doesn't. But I guess I didn't express
> myself clearly enough: it is not this simple string concatenation that
> I compare with ErlSql, but a similar library with the single
> difference that the API uses string-sql instead of erlang-sql.
>
> The comparison you make is unfair, because for example
> make_str_for_fields/1 is a library function. I bet ten pints of beer
> that OtherModule:shown_fields() does something very similar.

You owe me ten pints -- that function returns a list of atoms :)
- Show quoted text -

>
> So how would this alternative library look like? Taking your example
> and without any parse transformations or other non-standard
> functionality, I would like to see something like
>
> make_get_related_many_to_many_query(OtherModule, JoinTable, Obj,
> WhereClause, ExtraClause) ->
>    sql:build("select %L from %L "
>                 "  where (%s.id=%s.%s "
>                 "  and %s.%s= %s) "
>                 "  and (%s) "
>                 "  %s",
>     [OtherModule:shown_fields(),  [OtherModule:table(), JoinTable],
>      OtherModule, JoinTable, get_id_field(OtherModule),
>      JoinTable, get_id_field(Obj), get_id(Obj),
>      WhereClause,
>      ExtraClause]).
>
> This can be cleaned up a little (and your erlsql example too) by using
> some local variables. %L says the arg is a list of parameters.
>
> If we use a parse transform, the it may look even prettier (in my
> eyes, at least)
>
> make_get_related_many_to_many_query(OtherModule, JoinTable, Obj,
> WhereClause, ExtraClause) ->
>    sql:build("select %%OtherModule:shown_fields() "
>                 "  from %%[OtherModule:table(), JoinTable] "
>                 "  where
> (%OtherModule.id=%JoinTable.%get_id_field(OtherModule) "
>                 "  and %JoinTable.%get_id_field(Obj)=%get_id(Obj)) "
>                 "  and (%WhereClause) "
>                 "  %ExtraClause").

>
> What sql:build does behind the scenes is an implementation detail. It
> may put together strings (like io:format) or it may parse the sql,
> build a quasi-sql representation and work with it. As a user I don't
> care, as long as it does what it is supposed to do. I don't have to
> keep counting nested {}s and []s and to learn what in fact is a new
> query language (you already want to introduce new ways to write
> things).

Whether these examples look better or not than ErlSQL is in the eyes
of the beholder. I, personally, don't find ErlSQL expressions any
worse than the alternatives, but I would be happy to give the user
both options and let them pick whichever they prefer :)

To ErlSQL's advantage, I should say that emacs does a good job of
indenting your clauses and helping you balance all the parens, and it
has nice syntax colorization that make these expressions look better
than they do in Email. Also,
it's much cheaper to build ErlSQL in runtime than the first example because
it doesn't require any parsing.

Another benefit of ErlSQL is that when you pass an ErlSQL expression
as a parameter to different functions, it's easy for them to extract
information about its structure and values using pattern matching. In
ErlyDB, this makes writing adapters for non-SQL drivers (e.g. Mnesia)
much easier.


>
> BTW, how do you write 'join' statements? The natural way for an erlang
> data structure would be {join, {select,...}, {select,...}}, but that
> doesn't follow the way the sql looks like.

Right now explicit joins aren't part of the language simply because I
haven't needed them. Joins are implicitly expressed in FROM and WHERE
clauses.

>
> Having a new query language isn't a bad thing, but then it's not sql.

It's not SQL... it's an Erlangification of SQL :)

Cheers,
Yariv