[erlang-questions] Using -spec for callbacks when defining behaviours

[Vlad Dumitrescu]

On Wed, Mar 17, 2010 at 16:41, Kostis Sagonas <kostis@REDACTED> wrote:
> behaviour_info(callbacks) ->
>  [{init, 1,
>    "-spec init(Args) ->
>           {'ok', State} |
>           {'ok', State, timeout() | 'hibernate'} |
>           {'stop', Reason} |
>           'ignore'."},"},

While this is good because it is easy to implement and somewhat
compatible to the old way (cf the other comments), it has the distinct
feeling of a duct tape fix. At least to me it does.

Type specifications are part of the language, although not
expressions, as you point out. But is it a good idea to use them as
data by having them as strings? Tools will have to know that strings
returned by behaviour_info are to be interpreted as type specs. Soon
there will be other functions that could return those, and also other
metadata will be hidden inside strings. I don't know about you, but I
don't like that at all... Actually, I'd go further and say that the
current data returned by behaviour_info already suffers of the same
problem: tools have to know that "{init, 1}" in this case is in fact
"fun ?MODULE:init/1".

A way to handle this that keeps the data in a sane format would be to
introduce callback declarations, in the style of

-callback init/1.     %% old style
-callback init(Args) -> {'ok', State} | {'ok', State, timeout() |
'hibernate'} | {'stop', Reason} | 'ignore'.

The compiler would generate automagically behaviour_info from these
declarations, so that after compilation everything looks like in the
other case.

Looking at the resulting behaviour module, it looks funny: no
functions, just some declarations... I won't push this further now,
except to note that I can imagine taking several steps and seeing it
not as a module, but as an interface description. Replace -module()
with -interface() and then we could remove the -callback. I can see
this interface descriptions extending to address process interfaces,
something in the style of UBF(B). There's a lot of potential.

I am well aware that many will hate the idea (which can be improved),
but I'm sure that at least as many hate the idea of "strings as
complex data types that the compiler doesn't know about and tools have
to know about of all these special cases".

best regards,
Vlad