[erlang-questions] [proposal] Declarative syntax for metadata (long!)

Ulf Wiger <>
Sat Apr 10 13:58:11 CEST 2010

Michael Truog wrote:
> Hi,
> I was hoping to bring up this thread because it does relate to a task I
> am trying to do in Erlang.  To avoid re-parsing a compiled module to
> generate this information I was hoping to use the loaded binary beam
> data.  My use case is for automatically generating RPC function
> definitions from an API module, which I think would be neat.
> One small thing that would make this easier, is if
> "-compile(debug_info)." worked.  The documentation says it does:
> "Note that all the options except the include path ({i,Dir}) can also be
> given in the file" (http://erlang.org/doc/man/compile.html#debug_info)

The following code might serve as a quick-and-dirty workaround,
and also provide much faster access to the abstract code:


parse_transform(Forms, _) ->
     [EoF|Rev] = lists:reverse(Forms),
     Forms1 = lists:reverse([EoF,absfun(Forms)|Rev]),
     {Attrs,Funs} = lists:splitwith(fun(F) ->
                                            element(1,F) == attribute
                                    end, Forms1),
     Attrs ++ [{attribute,1,export,[{'$abstract_code$',0}]} | Funs].

absfun(Forms) ->
     {function, 1, '$abstract_code$', 0,

Eshell V5.7.5  (abort with ^G)
1> c(include_forms).
2> c(include_forms, [{parse_transform,include_forms}]).
3> include_forms:'$abstract_code$'().

The parse_transform directive can certainly be included in
a module, as well as buried in a .hrl file.

Ulf W
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd



Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.


More information about the erlang-questions mailing list