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

[Michael Truog]

On 11/26/2015 07:42 PM, Richard A. O'Keefe wrote:
> On 27/11/2015, at 2:35 am, Tristan Sloughter <t@REDACTED> wrote:
>
>> That's something the JIT should be doing, right?
> Answer: cross-module inlining *changes the semantics*
> of Erlang.  So with the exception of a handful of core
> system modules, I would hope that HyPE *doesn't* do that.
>
> Cross-module inlining should be licensed by an explicit
> declaration of some kind.  Back in the last century I
> proposed an
>    -import_static(Module, [...Function...]).
> directive to tell the compiler to bind the source module
> to the version of Module available at that time to the
> compiler (and to check at load time that the same version
> was used).

Having it be opt-in does sound good, but it should complicate
hot-code loading, making a module update possibly fail due to the
import_static dependency on an external module.  If module 'a' uses
import_static on module 'b', does the inlining (actual source code) of
module 'a' change during runtime if module 'b' changes?  When the
module 'b' update indirectly alters module 'a', does its module
version not change?  If you were allowed to do an update of a
module used for inlining, it could create a ripple-effect in the system,
making the process more brittle and prone to failure, due to the
lack of isolation.

If instead the modules that are inlined are marked "permanent" and
prevented from being updated in the future, then there is a reason
to not use inlining (which becomes problematic, since it is only
controlled in other modules that may be beyond the scope of your
development concerns (e.g., a lower-level library that you want to be
able to update in the future)).

You may be able to make a lens implementation that relies on
header file usage, which would allow all the functions to be within a
single module and allowed to be inlined there.  That approach
wouldn't cause problems for module updating in the future.