[erlang-questions] Coming Back (maybe improving lists:reverse/1)

[Richard A. O'Keefe]

On 14/10/2015, at 3:40 am, Ivan Carmenates Garcia <co7eb@REDACTED> wrote:

> Hi Richard,
> 
> Yes I will definably like to build queries like list comprehensions or like
> your nice example, but I don't understand so well parse transform because I
> didn't find so much documentation about it in Erlang doc, I was trying with
> qlc but yet nothing I could archive.


The basic idea is that the standard tools parse a module to get
an abstract syntax tree for the whole module, hand it to your
code to transform, and continue with whatever you give back.
The source code does NOT have to pass semantic checks; the result
of transforming does.

http://www.erlang-factory.com/upload/presentations/521/yrashk_parse_transformations_sf12.pdf

erl_id_trans is an example module that does nothing:
http://www.erlang.org/doc/man/erl_id_trans.html

It's worth noting that you can use an identity parse transform
as a way of plugging in a static check of some kind that is not
already done by the compiler.

The warnings in that are a little strong.  Parse transformations
are not something to do *lightly*, but for implementing a query
language as an Embedded Domain Specific Language they are a good
choice.

The Stack Overflow query "Is there a good, complete tutorial
on Erlang parse transforms available?"
http://stackoverflow.com/questions/2416192/is-there-a-good-complete-tutorial-on-erlang-parse-transforms-available
has some useful answers.

http://seancribbs.com/tech/2009/06/21/building-a-parser-generator-in-erlang-part-4/
talks about parse transforms in the context of building a PEG
parser generator for Erlang.  I liked it, except that it is a
*perfect* example of why syntax colouring is **evil**.

The official definition of abstract syntax trees is the
documentation for the erl_syntax module:
http://erlang.org/doc/man/erl_syntax.html

Justin Calleja has a nice introduction to that:
http://www.ricston.com/blog/erlang-erlsyntax/

Parse transforms are an extremely powerful tool that you want to use
*sparingly*; only when it will improve the *total* maintainability
of your program.  I haven't used them in anger yet in Erlang myself.
I've used the equivalent in other languages to do things like
embedding XML syntax in a host language and generate specialised
code from a template.  (The effort of trying to take three versions
of the "same" thing and boil them down to a single template from
which the originals can be recovered is, sadly, a good way to
discover *unintentional* differences between the versions, which is
why I think maintaining a master copy and generating specialised
versions from it is a good thing for overall maintainability.)

There are at least four ways in which a parse transform can help
with an embedded query language:
 - queries can be much easier for people to read and write, so
   the queries as such can be more maintainable
 - what the translation *is* can be varied without the source
   code of any query having to be changed
 - the translation is done at compile time, not run time
   which is good for efficiency *and* timeliness of error reporting
 - the temptation to leave a sanity check out on the grounds that
   it will cost too much at run time goes away because you know the
   check will be done at compile time.

*Can* help is not *will* help.  But it's worth exploring.