[erlang-questions] Proposal: a new Dbgi BEAM chunk
Tue Mar 14 10:49:24 CET 2017
On 03/13/2017 01:55 PM, José Valim wrote:
> Many tools in the Erlang ecosystem expect the Erlang Abstract Code chunk
> to exist or, if it doesn't exist, it automatically generates one from
> the source code, if it can find the respective Erlang source.
This is the point where I got confused...
- What does the mechanism that finds the source code have to do with
the new chunk which is stored in the .beam file? These two are totally
orthogonal mechanisms, aren't they?
- How is finding "the respective Erlang source" related to solving the
problems that LFE or other languages (existing and future ones) may be
facing? Does the proposal come with some magic mechanism to "find" (I
guess "generate" is a more appropriate word here) Erlang source code
from e.g. LFE source?
Don't misunderstand me, I am not necessarily against the proposal. It's
just that I do not see why/how renaming a BEAM chunk is helping us solve
problems that are orthogonal to the info that gets stored in this
> Therefore we need a mechanism to store abstract code on .beam such that:
> * The abstract code is stored once but can be retrieved in different
> formats, as supported by the initial language (where the initial
> language is erlang, core, lfe, elixir, alpaca, etc)
> * If the abstract code is omitted, we should still provide the ability
> to retrieve it from source if desired, regardless of the initial language
Does this mean that it will be impossible to hide the original source
code from now on?
Does this mean that if I have a .beam file lying around from long ago or
I have written a compiler that generates .beam files without a .Dbgi
chuck this is not a valid .beam file anymore? How is that "backwards
compatible"? (as claimed in the PR)
Apologies if I have misunderstood something...
More information about the erlang-questions