[erlang-questions] Updates, lenses, and why cross-module inlining would be nice
Richard A. O'Keefe
Wed Dec 2 05:06:15 CET 2015
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, ...)
(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.
More information about the erlang-questions