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

[Michael Truog]

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)

For my use case, if that worked, I could just insert the debug_info
compile option into the API module and then have access to the code from
the binary beam format, with something like:
{_, Beam, _} = code:get_object_code(Module),
% example in http://erlang.org/doc/man/beam_lib.html
{ok,{_,[{abstract_code,{_,AC}}]}} = beam_lib:chunks(Beam,[abstract_code]),
io:fwrite("~s~n", [erl_prettypr:format(erl_syntax:form_list(AC))]).

With the absence of the "-compile(debug_info)." I must use manual
re-parsing of the module if I want to avoid unique command-line
configuration for module compilation... and that seems silly.

The abstract_code format does not provide the preprocessor/comment
lines, but it doesn't seem as if it would be a problem to add that data,
except for the bloat of the debug data.

Applications can always be queried through:
 [{FirstApplication, Description, Vsn} | _] =
application:loaded_applications(),
{ok, ModuleList} = application:get_key(FirstApplication, modules).

I agree that these tasks could be made a little easier by gathering them
into a single place somehow.

- Michael

Vlad Dumitrescu wrote:
> On Thu, Mar 18, 2010 at 14:06, Joe Armstrong <erlang@REDACTED> wrote:
>   
>> We should be able to introspect a module at run-time and recover a
>> list of funs, we should be able to take a fun and recover its syntax
>> tree or an ascii representation of the fun. The same should be true
>> for types, specs, edoc strings an so on.
>>     
>
> Yep, that too! I think even applications could exist as 'things': get
> a list of applications, query an application for its modules.
>
> <sidenote> There is no such thing in Erlang as a module, just a name
> in the documentation and the attribute with the said name. Otherwise
> one does handle and refer to beam files. There should be an API to
> handle modules that hides the underlying beam_lib, as an example.
>
> regards,
> Vlad
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>
>