[erlang-questions] idea: function meta data

[G Bulmer]

Lovely idea.

I had imagined that type part of this was already done by the Erlang  
type contract syntax checker (in Erlang Workshop paper "A Language  
for Specifying Type Contracts in Erlang and its Interaction with  
Success Typings", and mentioned in "I want documentation of Erlang in  
EDoc format" on this list).

Specifically, there is/will be a parser for the type contract, and  
tooling which checks the type contract specification matches the  
actual function (in some useful sense). Storing the parsed type  
contracts in the compiled file seems to solve potential problems.

So, the idea here is to connect together even more function metadata  
too, and store it in the code file?

So, I don't understand the need for "int -> int".

How about using the type contract syntax:
-meta(type, function_name/N, type_contract).  %% where type_contract  
uses the proposed type contract syntax
This would interpolate the function name and a type contract  
representation into the metadata stream.
Then follow it with something slightly different, e.g. meta_attr(...)  
which adds attributes to the most recent meta(...).
The idea is to use the function name and type contract as a  
consistent, unique, key within the module, and hence across a running  
system.

Then the standard for the unique key is 'done', and everything else  
becomes name value pairs.

If this were the path followed, we would need to have the type  
contract available at run time.

This would also provide a handle which could be used to check type  
compatibility of functions within modules without needing external  
infrastructure.

I've read some papers (at: http://groups.csail.mit.edu/pag/reading- 
group/, maybe in 2005) about tooling which uses related techniques to  
support global program analysis to enable analysis to scale to  
enormous systems (where complete source analysis might not scale, or  
where source code may not be available).

G Bulmer

PS - I'd seperated the type contract from the function name so that I  
could use macro replacement for type contracts if I had a family of  
functions, and maybe the key would be a tuple, so I could get all  
meta data for the same function name, irrespective of arrity or type  
contract. but that may be making it too complicated.

> From: "Joe Armstrong" <erlang@REDACTED>
> Subject: [erlang-questions] idea: function meta data
>

> Module have metadata  Mod:module_info(export) etc.
>
> But functions do not.
>
> idea - attach function meta data with a new attribute.
>
>      -meta(doc, "the factorial function").
>      -meta(type, "int -> int").
>      -meta(keywords, [math]).
>
>      fac(0) -> 1;
>      fac(N) -> N*fac(N-1)
>
> The meta data gets *attached* to the Next function in the module
>
>     -meta(process, true).
>     foo() -> spawn(fun() -> ... end)
>
> After compilation meta data can be access as follows:
>
>    Mod:meta_data(fac, 1, doc) => "the factorial function"
>    ...
>    Mod:meta_data(fac, 1, glurk) => '$nothing'
>
> if we then *standardise* the meta data it will be easy to make loads
> of nice tools for type checking, documentation etc.
>
> I'm off on a trip today - so can somebody hack the preprocess and
> parser to do this? (( this needs a small change
> attributes have a different syntax and must be at *before* all  
> functions))
>
> This adds introspection to the language !
>