Shock horror

[Richard Carlsson]

On Thu, 2 May 2002, Vlad Dumitrescu wrote:

> If I may add my humble opinion, this is why having a
> "-uses([module])." or similar would help - by making the relations
> between modules explicit. This might even encompass applys with
> variable arguments - only calls to listed modules will be allowed.

Then the gen_... modules, and any others using callbacks, would not be
possible if this was strictly enforced. Furthermore, that kind of
declaration has an inherent problem: they tend to be always outdated.
For instance, you specify that M uses M', but then later someone edits M
so that it no longer actually uses M', and forgets to remove the
declaration.

The information is already there: you don't need a -uses declaration
just to duplicate it, with all the trouble that brings. Someone please
write a decent front end to xref that reports the module dependencies
(or writes them to a file) so that you don't have to look up the xref
manual each time, and put it in the standard distribution. Erlang is a
very dynamic language - let's not clutter it with unnecessary static
declarations.

> I think that not shipping everything is not necessarily good - what
> if one later loads new code that relies upon some less used stdlib
> module? One should have then to keep track of what was delivered
> where, and it is difficult in the long run even for such hard
> constrained environments as Ericsson's. Also, what if an operator
> might be allowed to access the Erlang shell - he/she wouldn't have
> access to the absent functionality...

I think what we need is a reasonable layering of the libraries, not a
fine-grained "is this module strictly necessary?" approach. So for a
standalone application, only the most basic runtime libraries and a few
libraries used specifically by the application would be needed (and
maybe stripped to the bare bones before shipping, as suggested). For a
small distribution which normally starts a shell, most of the standard
libraries should be available, but probably not things like ASN1, Corba,
(Java support?), Megaco, and other things; these can be installed
separately if needed. A "telco toolkit" distribution would include all
the snmp/asn1/godonlyknows stuff. And so on. It's a question of
identifying the layers and doing some restructuring, mainly of the
kernel/stdlib modules.

	/Richard


Richard Carlsson (richardc@REDACTED)   (This space intentionally left blank.)
E-mail: Richard.Carlsson@REDACTED	WWW: http://www.csd.uu.se/~richardc/
 "Having users is like optimization: the wise course is to delay it."
   -- Paul Graham