Shock horror

[Vlad Dumitrescu]

>         a) Things may load slowly
>	b) It becomes increasingly difficult to ship stand-alone
>	   applications since nobody is really sure of what code is needed.
>
>   A consequence of c) is the *ship everything* mentality.
>
>   I'm going to take a good hard look at the system to see if we can't
>identify a minimal kernel ...

Hi,

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.

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...

However, should one be sure that the code base is fixed or the whole system 
will be upgraded, then it is also possible to have an additional step after 
the compilation, where all unused modules (maybe even functions) can be 
removed from the delivery. Of course, this is not trivial without things 
like "-uses([module])." or "-uses([mod:fun/x]).".

just some thoughts. Regards,
Vlad

_________________________________________________________________
Skicka och ta emot Hotmail-meddelanden på din mobilenhet: 
http://mobile.msn.com