[erlang-questions] Is -on_load() still experimental? Anyone using it?

[Richard A. O'Keefe]

There is a long history behind things like -on_load(),
and it's largely a long history of pain and woe.
Just recently, for example, I've been reading about
the problems this can cause in .NET.

There is a minor problem of controlling the order in which
-on_load code is executed.

Section 10.2.1 of the Ada 2012 standard, for example,
describes 
	pragma Elaborate(library_unit_name{, library_unit_name}...);
which says that each of the named library units must be fully
initialised before this one comes up.

In my own Smalltalk system, where the equivalent of a module is
a class, I found it necessary to add an
	initializeAfter: 'class...'
property to control the initialisation order, and I remain
grateful to the Ada designers for showing me what exactly what
I needed.  (The usual symptom was something crashing in
initialisation because the I/O subsystem wasn't up yet.)

The major problem is when there are dependency cycles so
that there isn't _any_ consistent order.

Suppose we have two modules, ping and pong.
The -on_load code for ping needs to call something in pong.
The -on-load code for pong needs to call something in ping.
OOPS.

It's way too easy to get into that situation (*especially* in
Java and .NET, where the result isn't a lockup but a mess).

It should be possible to build tools that will detect
-on_load cycles.  Not until such tools are deployed AND
there is a way to state load order dependencies in a
module that uses it could
-on_load be anything but experimental.  It requires serious
inspection to make sure there are no cycles and no order
dependencies if you use that feature.

Oh yeah, there's another issue which used to bite me a lot
in Interlisp-D, and that's modules that could be loaded but
not *re*loaded.  The example in the manual bothers me
because 
  - it doesn't say "here's how to leave the NIFs alone
    if they're already loaded and right"
  - it doesn't say "here's how to unload the NIFs and
    load new versions if they're already loaded and wrong."
  - it doesn't even say "here's how your -on_load code
    can find out which situation it's in"
One of the reasons for using Erlang is to support fix-and-
reload in running systems, and while -on_load isn't
*necessarily* incompatible with that, -on_load hands you
the tools you need for *you* to make your code unreloadable.
At a minimum, I would want to see
	-on_load(Name/1).
allowed with Name being called as
	Name(load)
or	Name(reload)
but I'm sure someone can think up something better.