[erlang-questions] Updates, lenses, and why cross-module inlining would be nice

[Richard A. O'Keefe]

On 1/12/2015, at 8:42 am, Michael Truog <mjtruog@REDACTED> wrote:
> The header approach is preferable to make the dependency problems
> a compile-time concern, rather than creating a runtime failure when
> attempting a module update.  It is important to not crash running source
> code due to errors.

It *would* be "preferable to make the dependency problems
a compile-time concern".  But using headers DOES NOT DO THAT.

Nor does the import_static approach "crash running source code
due to errors."  import_static has two purposes:
(1) to permit cross-module inlining and type inference safely;
(2) to detect a clashing update *before* changing the state of
the system in order to *avoid* crashing running source code.

It is precisely the header approach which *creates* the potential
for runtime problems due to version skew issues NOT BEING NOTICED.

For what it's worth, I have a version of lens.erl as lens.hrl.
It's not a pretty sight.
There's heavy use of a ?LET macro to try to avoid variable
capture, multiple evaluation, and so on.
It relies a lot on the compiler inlining
 (fun (X, ...) Body end)(E, ...)
into
 (X' = E, ..., Body, kill X'...)
which, sadly, it does not appear to do.

> The point of this, is to show the same source code can be used, with
> inlining, and that the potential for breakage can be handled with testing
> all the functions.  A lens interface should not change a whole lot, so it
> can be a dependable interface that is trusted.

Nobody is suggesting that import_static should be COMMON or
used with frequently changed modules, only that something a
bit more disciplined and rather safer than a horrible mass of
-defines woukd be nice.

>> 
>> RIGHT NOW you can get mysterious errors that go away
>> when you recompile things, due to the use of headers.
>> import_static doesn't increase the problems, or the
>> amount of work you have to do to fix them, or the nature
>> of that work.  All it does is give the system a chance
>> to *notice* that the problem already exists.
> Yes.  I believe this doesn't become a concern when tests are provided.

If the modules in question are tested *separately*,
the tests don't help.  If you test the modules *together*,
you might as well *reload* them together.