During the start of the eleventh week, I kept working on the tests for the simplified ETK backend I talked about the previous week. An important update is that, after testing some features in my ERC20 implementation, I found a bug. This bug was in how macros are handled, and it's related to how the original ETK frontend was built. I discussed this with Sam Wilson, a big name in the ETK project. After our talk, he told me it was okay to keep the grammar as it was, but maybe remove some of the other code.

After that decision, I used much of the week trying to understand the code better (not just the assembler part) and thinking of how to solve this macro problem.

But before I share my idea, it's good to understand that ETK has two special operations to include files:

• %import(path): It's like taking the code from the given path and putting it directly where you called this operation.
• %include(path): It's almost the same as %import, but the code you bring in is kept in a different scope and doesn't mix with your main code's positions.

Also, in ETK, you can create macros. This lets you use a group of operations many times without writing them again and again. And you can define macros anywhere, even after you've already used them in the code.

For instance, this is a correct piece of code:

%macro foo()
    push1 0x02
    jump
%end


start:
    jumpdest
    pc
    %foo()

Now, my main idea was:
In the original ETK frontend, the compiler looks at the main file and leaves each include/import as a simple node with just its path. When the compiler gets to this node, it goes and gets the code from that path. I thought this made things complicated because you had to keep track of different sections and some code was hidden. Also, you couldn't do any preprocessing.

I thought of a different way. I wanted to solve these paths right in the parser. So, after the parser is done, we have a big list of all the operations. I think this is better because:

• Before turning operations into bytecode, I can see all the macro definitions. Since using a macro can mean adding many operations, waiting to know what the macro does makes things more complicated, especially with labels (remember that using a label is just saving the position where the label is defined).
• If all the operations from an include are already there and ready, it's easier to manage the code's sections. I can just take all the code, use a new assembler instance, and let it work like it's a new program.

But, I have to be honest. My first try wanted to do many things at once. The results were okay, but the code was too messy. It was hard to read because everything was mixed up.

For the next week, I want to make the code simpler. Maybe it will be a bit slower, but it will be much clearer what each part does. This will make it easier for people to help with ETK in the future. And if we need to make it faster later, we can do that in another PR.