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

[Ciprian Dorin, Craciun]

On Thu, Mar 18, 2010 at 1:34 PM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> Hi all,
>
> I feel I should follow up on my rant from last night (I hope the tone
> wasn't too harsh!). I have been thinking about these things for a long
> while, but I'm sure I still miss some points.
>
>
> Erlang source code contains besides actual code even meta-data and
> configuration data, disguised as Erlang terms, comments or strings.
> Some of this data has been integrated into the language (type
> specifications, for example), but not all of it. I would like to
> present arguments for and against integrating all such data.
>
> First a non-exhaustive list of data that IMHO would benefit from
> becoming a first-class citizen of the language:
> - behaviour callback specifications
> - supervisor child specifications
> - match specifications
> - edoc
>
> Today, there are three ways to encode this data: as Erlang terms, as
> strings and as comments. (I know strings are terms, but they are
> different)
>
> [... snip, snip, a lot of snip snip ...]
>
> best regards,
> Vlad


    (Disclaimer: I'm a big fan of Erlang, studied it, played with it,
and only lately used it for something non-trivial, so please take my
comments lightly.)
    (2nd disclaimer: I'm not wanting to start a pro-, or con-debate of
what I'm going to describe. I've already did this a year or two ago on
this mailing list.)

    What Vlad is describing here as `meta-data and configuration data,
disguised as Erlang terms, comments or strings` and then he points
them out: behaviour and supervisor specifications or match
specifications, sounds to me like DSL's...

    So even though I'm not going to pronounce the magic word (ma***s)
I would like to add that all these (and more) can be solved by
allowing users to define their own custom languages.

    Ciprian.

    P.S.: After using Erlang a little bit more serious, I've found
out, that at least for gen_servers, there is a lot of boiler plate
code that one must write: `gen_server:call` wrappers... So I've
actually invested a lot of time in writing `define`s that abstract
away a lot of boiler-plate code... But believe me the result is
ugly...