[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