> On 18 Jan 2019, at 14:26, ducasse <stepharo@netcourrier.com> wrote:
>
> I simply love the dynamic rewriting this is just too cool. We should systematically use it.
> I will continue to use it in any deprecation.
>

On my TODO is to make it stand-alone and provide is as a ���compatibility transform���, too.

So we can add it to methods that we want to keep for compatibility, but they will nevertheless transform the code automatically.
(this then might be disabled in production to not transform)

> Now I have a simple question (You can explain it to me over lunch one of these days).
>
> I do not get why RBAST would not be a good representation for the compiler?
> I would like to know what is the difference.
>
I think it is a good one. I have not yet seen a reason why not. But remember, Roel left Squeak because his visitor pattern for the compiler was rejected as a dumb idea��� so there are definitely different views on core questions.

E.g. the RB AST is annotated and the whole things for sure uses a bit more memory than the compiler designed for a machine from 1978.

> You mean that before going from BC to AST was difficult?

You need to do the mapping somehow, the compiler needs to remember the BC offset in the code generation phase and the AST (somehow) needs to store that information (either in every node or some table).

> How opal performs it? It does not use the source of the method to recreate the AST but he can do it from the BC?
>

It uses the IR (which I still am not 100% sure about, it came from the old ���ClosureCompiler��� Design and it turned out to be quite useful, for example for the mapping: every IR node retains the offset of the BC it creates, then the IR Nodes
retain the AST node that created them.

-> so we just do a query: ���IRMethod, give me the IRInstruction that created BC offset X. then ���IR, which AST node did create you? then the AST Node: what is your highlight interval in the source?

The devil is in the detail as one IR can produce multiple byte code offsets (and byte codes) and one byte code might be created by two IR nodes, but it does seem to work with some tricks.
Which I want to remove by improving the mapping and even the IR more��� there is even the question: do we need the IR? could we not do it simpler?

The IR was quite nice back when we tried to do things with byte code manipulation (Bytesurgeon), now it feels a bit of an overkill. But it simplifies e.g. the bc mapping.

�� �� �� �� Marcus