[erlang-questions] Erlang way for process-as-library?

[ok]

Because my e-mail client flipped a few key settings without me knowing
about it, I ended up replying to some mail from February, mentioning
my old -export_to() proposal.

On 24 Apr 2007, at 7:11 pm, Vlad Dumitrescu wrote:
> This gives me an uneasy feeling: it means that a process should be
> aware of the possible clients...

It doesn't mean that at all.  It's not a *general* replacement for
-export; it is specifically a way of dealing with the case where the
module designer *DOES* know all the intended collaborators.  It is
for the case where a single *application* is produced as several
*modules*, and for lack of precise export we currently have the rather
disgusting and dangerous situation that a function *intended* for use
by a specific sibling module has to be exported to the whole world.

One of the things it is intended for is behaviours.  A behaviour
defines a callback protocol.  A client of the behaviour has to
export those callback functions to the behaviour.  For lack of any
more precise declaration, it has to export all the behaviour callbacks
to the whole wide world.  And that means that you cannot trust the
behaviour callback protocol, because those functions might be called
by anybody with any arguments.  Passing funs is no real remedy, because
you want these functions to be replaced when the module is reloaded.
>
> Another way to to the same thing is to have separate modules export
> different interfaces and just delegating to the base module. This can
> be implemented as a parse transform where a declaration in the lines
> of
>   -interface(Base_Module, [Fn/Nn...]).
> would be expanded to the required function definitions.
>
> Alternatively, the base module could contain
>    -interface(Interface_Module, [Fn/Nn...]).
> and the Interface_Module module would be generated dynamically in  
> its entirety.

I don't understand this proposal.  I am in general sympathetic to the
idea of modules having more than one interface.  (This is a key part of
the ISO Pascal Extended design, and it's also part of Zonnon, the latest
member of the Pascal/Modula/Oberon family.)  Could we have more detail?

> Of course, the base module can still be called directly, but it  
> shouldn't be.

"Shouldn't be" is not as useful, for writing reliable software, as
"can't be".  The point of adding -export_to is to make some "CAN'T BE"
guarantees, and any rival which doesn't achieve that misses the point.