This week, my work was mainly focused on finishing the assembler simplification I talked about last week.

In the first instance I started working on a fairly basic but not very efficient simplification, which can be seen in [PR #132](https://github.com/quilt/etk/pull/132). From the text of the PR itself it reads:

> This is a WIP of the assembler simplification.
The main idea is to drop the use of the pending vector that accumulates bytecodes until the definition of a label is reached.
>
>There is still a lot to optimise, but the general idea is as follows:
>
> - Scan the code to identify labels and macros (surely this can be removed).
> - Process the code in its entirety, expanding macros where possible and saving label positions as they appear.
> - A final pass to concretise all the labels, assigning them their corresponding value.
>
>As I said before, this is still a work in progress, as I don't think it's necessary to do three passes through the code.

However, this first approach gave me a deeper understanding of how the assembler works, and I noticed that the simplification in question could be tackled without the need for several of the operations used in the previous PR. Therefore, I decided to tackle the problem from scratch again and that is how [PR #133](https://github.com/quilt/etk/pull/132) was born. We can see the basic ideas of this implementation from the text of the PR itself:

> This PR simplifies the operation of the assembler, mainly by removing the need to maintain a pending state and to return the assembler to its original state in certain situations (which caused [issue #124](https://github.com/quilt/etk/issues/124)).
>
> The main changes include:
>
>
> - The creation of two structs, PendingMacro and PendingLabel, which store information about the macros and labels used before they were defined, as well as their relative position in the code.
> - Some push operations have been changed to take an option as parameter, and if this is not None, to act more like an insert than a push (useful for example to insert the calls to the pending macros).
>
>Also, issue #124 has been fixed and the corresponding test added.
>
>All tests should pass successfully. However, I would like to test the new assembler a bit more by writing some code (e.g. following @lightclient 's recommendation and writing an ERC-20 implementation using ETK) before merging it.
>
>In case you don't find it necessary, it can be merged right now.

As mentioned in the same text, this PR also solves [issue #124](https://github.com/quilt/etk/issues/124), which was in the list of "possible tasks after EOF" that I talked about with lightclient.

While all the tests pass correctly, I'm interested in testing the code a bit more by implementing some short example code, like an ERC20, which can also serve to add to the examples section of the documentation, which is empty at the moment.

___________________

So, the tasks for next week are:

- Implement a version of the ERC-20 standard in ETK to add to the list of examples and, by the way, look for possible bugs in the assembler.

- Follow up on the EOF implementation and the possible modifications we were going to make to solve the opcode renaming/deprecation issue I talked about a few weeks ago.