Language specification and miss2

[x87]

This is a discussion on making a decision on whether to follow language boundaries set by the official miss2 compiler or not.

My vote is that the language must be consistent and bugs-free. The (only?) existing implementation of it (miss2) does not follow this rule only providing a tool being able to work with limited set of programs, sufficient for DMA at time of writing. Introducing quirks into the spec will limit future implementations and will make development and supporting it a complicated process.

As a possible step in future a limited subset of this specification could be designed to conform with miss2 behavior.

[thelink2012]

This is the way I see it:

The repository should be divided into three parts:

1. The core language specification.
2. The game extensions.
3. The community extensions.

The core language specification should be whatever the miss2 v413 recognizes minus the bugs and limitations. It is what is known from reversing official sources. No additions to the syntax. Guessing might be necessary for subtracting buggy syntax, defining terminology and specifying some of the constraints and semantics. Nevertheless, all guessing must be accompanied by a rationale in the Rationale subsection of the appendix (not yet there). Discussion on guessed stuff is encouraged.

The game extensions is a document for each of the games that:

• Define the implementation limits (e.g. maximum of 8 conditions in a conditional list).
• Subtracts features from the core (e.g. Vice City does not support IFNOT).
• Adds its own features which are yet syntactically unknown to the community (e.g. SWITCH). Although some of those additions have very good guesses from analyzes of leaks (e.g. we know the high-level commands used to implement SWITCH, thus we know the syntax), they are still guesses and should not be part of the core.
• Defines game-specific commands that need help from compiler to get translated (e.g. SET_COLLECTABLE1_TOTAL).
• Define code shape (and similar low-level details) for each statement as deterministic code generation is required in order to not break save games. Rockstar did not care, but well..
• Define the implementation-defined behaviours from the core, and perhaps some of the unspecified ones.

They should still be whatever miss2 would probably be doing in versions of the compiler we don't have. As usual, every guess should be accompanied by a rationale in the appendix. These extensions still use as much formalism as the core specification.

The community extensions is where we can make our own touches to the language.

For each community extension there must be an informal specification.

The process of adding an extension should be as lightweight as possible. Any person should be capable of doing it, thus why it should be informal (although following a predefined document structure).

The Rust RFC process is a very good example of how these extensions should be handled.