Metaprogramming

From Erlang Community

(Difference between revisions)
Revision as of 11:33, 22 September 2006 (edit)
Vladdu (Talk | contribs)
m
← Previous diff		 Revision as of 11:35, 22 September 2006 (edit) (undo)
Vladdu (Talk | contribs)
m
Next diff →
Line 37: Line 37:
Wouldn't it be wonderful if one could combine the two? That is, one would write the textual form but behind the scenes handle the parse tree. Wouldn't it be wonderful if one could combine the two? That is, one would write the textual form but behind the scenes handle the parse tree.
</p><p> </p><p>
-For example, the user writes <code>X = "select id from users"</code> and the resulting beam code is in fact <code>X = {select, [{fields, [id]}, {from, [users]}]}</code>.+For example, the user writes <code>X = "select id from users"</code> and the resulting beam code is in fact just as if he/she had written <code>X = {select, [{fields, [id]}, {from, [users]}]}</code><br> Okay, this is svery simple, but I promise there will be mode complicated exmples later on!
</p> </p>
===Handling Erlang code=== ===Handling Erlang code===

Revision as of 11:35, 22 September 2006

Contents

Author

Vlad

Overview

Here I will gather some thoughts about metaprogramming in Erlang. Hopefully this will result in an implementation too (some parts have already been implemented). I put this here so that I can get input and the result will become a HowTo.

This is very much a work in progress. Please don't delete anything, just add your comments.

What is metaprogramming?

I won't go into the gory details here, there are plenty of papers on the matter. What I do mean by MP here is the capability of writing programs that handle programs.

Current status

Erlang has already support for MP. It is composed from two parts:

  • the parse trees for Erlang code are regular Erlang terms
  • through the parse_transform concept, one can manipulate a module's parse tree before it is compiled
This is enough for quite advanced applications, but has the disadvantage that it's quite unwieldy and thus few have ventured into that area. Ulf Wiger has written code to make development of parse transforms easier. Another issue is that one has to use Erlang syntax for all extensions, which might make them not so easy to read and use.

MP extensions

There are several areas where MP would be useful.

Embedding domain specific languages

One example discussed recently is SQL.

Sometimes one wants to be able to use a DSL inside Erlang code. This can be done today by using the textual representation of the DSL code, which is prone to errors, or by using an Erlang representation of that code (i.e. a parse tree), which is great for matching and traversing but may be quite far from the original representation and the user is required to learn the new one.

Wouldn't it be wonderful if one could combine the two? That is, one would write the textual form but behind the scenes handle the parse tree.

For example, the user writes 

X = "select id from users"
and the resulting beam code is in fact just as if he/she had written 
X = {select, [{fields, [id]}, {from, [users]}]}

Okay, this is svery simple, but I promise there will be mode complicated exmples later on!

Handling Erlang code

Macros

License

The code associated with this HOWTO is available under a license to be defined.

Disclaimer

Don't blame me if this stuff blows in your face or if your cat starts barking like a dog! :-)

Retrieved from "http://www.trapexit.org/Metaprogramming"
Erlang/OTP Projects
Personal tools