[erlang-questions] idea: function meta data

Andreas Hillqvist andreas.hillqvist@REDACTED
Fri Nov 16 09:48:57 CET 2007


You make a good point.

So would this look like:
     -module(test).
     -doc("Math module with some fancy math functions.").
     -keywords([math, fancy, factorial]).
     -export([fac/1].

     -doc("The factorial function, for they day you will need it.").
     -keywords([math]).
     fac(0) -> 1;
     fac(N) -> N*fac(N-1)

I believe Erlang supports multiple occurrences, example a hlr is
expanded by the pre-parser to:
     -file("/xxx/yyy/zzz.hrl", 1).
     -hrl_id(aaa).
     -hrl_vsn(bbb).
     -hrl_date(ccc).
     -hrl_author(ddd).

     foo() -> bar.

Where hlr headers seems to be prefixed with hlr. So to differentiate
module level headers from function level we may use the "fun_" prefix
on atoms:
     -module(test).
     -doc("Math module with some fancy math functions.").
     -keywords([math, fancy, factorial]).
     -export([fac/1].

     -fun_doc("The factorial function, for they day you will need it.").
     -fun_keywords([math]).
     fac(0) -> 1;
     fac(N) -> N*fac(N-1)


Just my ideas/suggestions, pleas feel free to criticize.
   ;-)


Regards
Andreas Hillqvist

2007/11/15, Lev Walkin <vlm@REDACTED>:
>
> One of the most peculiar problems people have with certain languages
> (Objective-C) is that punctuation and non-alphabetical characters
> are overloaded beyond all reason. +module, -interface, @end, etc.
>
> We risk ending up with something like
>
> -module(test).
> +module(test).
> @module(test).
>
> where module is a keyword in one place and atom in another. Having
> more or less uniform "-<keyword>(<value>)." is arguably more
> self-consistent and removes unnecessary learning curve.
>
> Just 2c.
>
> Andreas Hillqvist wrote:
> > I like the Idea of function meta data.
> >
> > But it might be better/simpler/easier/harder to use an alternativ
> > prefix, like double -- (Similar to %, %% and %%%).
> >
> > Why not use the name atom instead of meta?
> > To me meta dose not contribute with value to the syntax.
> >
> > Would look like:
> >
> >     -module(test).
> >     -export([fac/1].
> >
> >     --doc("the factorial function").
> >     --type("int -> int").
> >     --keywords([math]).
> >     fac(0) -> 1;
> >     fac(N) -> N*fac(N-1)
> >
> > Or some other prefix like "+"(Just an example, Do not like + myself.
> > To much alike the udiff format. ;-)?
> >     -module(test).
> >     -export([fac/1].
> >
> >     +doc("the factorial function").
> >     +type("int -> int").
> >     +keywords([math]).
> >
> >     fac(0) -> 1;
> >     fac(N) -> N*fac(N-1)
> >
> >
> > Regards
> > Andreas Hillqvist
> >
> > 2007/11/15, Joe Armstrong <erlang@REDACTED>:
> >> 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 !
> >>
> >> /Joe Armstrong
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://www.erlang.org/mailman/listinfo/erlang-questions
> >>
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
>
>



More information about the erlang-questions mailing list