Transformation and Transformer Locking

[CheaterCodes]

Background and Terminology

At the start of Chasm, all Transformers are created, usually read from Chassembly files. They can declare ordering relative to other transformers. According to the specified ordering, Transformers are sorted into (as few as possible!) so-called "Rounds". The rounds are then applied one after the other. Therefore, a Transformer experiences the following relevant steps in its lifetime:

1. Creation (Start of Chasm)
2. Application (Start of Round)
3. Completion (End of Round)
4. Destruction (End of Chasm)

At the start of a round, during transformer application, a Transformer can create any number of Transformations. A Transformation declares during creation which segments of code it requires read access to, called Sources, as well as one primary Target it will replace on application. The Transformations of all Transformers that are running in the current round are then sorted to ordering implied by the Sources and the Target.

Analog to the Transformer, a Transformation at most lives through the following steps during its lifetime:

1. Creation (Transformer application)
2. Application (Replacing Target)
3. Completion (End of Round)
4. Destruction (End of Chasm)

Internally, Chasm only differentiates between Target and Sources by their writability. For the remainder of this discussion, Target therefore either refers to the single writeable Target or any one of the read-only Sources.

Locking

The idea of locking is, to allow a Transformation to declare restrictions on which Targets and Sources may be modified by other Transformations. In theory, locking can be performed on different levels:

• Transformer-level locking
• Transformation-level locking
  More granular targets are preferable, but a lock may only use lifetime events from its current level.

Affects on Ordering

The fundamental goal of Chasm is to apply as many Transformations as possible without violating any contracts. Some contracts are implied by the specified Targets (write inner before outer), but many of them are defined via locking. Therefore, locking on Transformation-level is a fundamental requirement as it is the primary way to affect ordering.

Locking on Transformer-level would allow the possibility to also affect ordering of Transformers, but it is unclear if this is something that is wanted.

Current Locking

Currently, we only use Transformation-level locking. Additionally, Locks can't outlive a Transformation, so we're limited to the following lock options:

• Lock from start of round until Transformation application (Lock.Before)
• Lock from Transformation application until end of round (Lock.After)

Questions

With this background, the following questions require discussion

Is current locking sufficient?

Imagine a mod that has only a single transformer for it's entire functionality. A different mod might modify the same code, silently overwriting the original mod. This is a conflict that would be currently detected, but only if they both run in the same round.

The current solution would be to have the first mod generate an additional transformer running in the very last round, which verifies correct application or crashes otherwise.

Do we want longer lived locking?

This would allow us to create locks that last past the end of the current round. The above example could instead create a lock that last from after application to the very end of Chasm.

Do we want Transformer-level locking?

Declaring locks on Transformer-level would allow us to create earlier locks, e.g. from that start of Chasm until Transformer application. I'm not sure this is sueful in any way, but if someone has a usecase, let me know.