[erlang-questions] Proposal: a new Dbgi BEAM chunk

[Kostis Sagonas]

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 
particular chunk.

> 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...

Kostis