+
+**Update:** I realized I should probably expand on the parenthetical remark about specifying MIR rather than specifying Rust.
+What we are planning to do here is to specify Rust by specifying (a) how Rust code translates to MIR, and (b) specifying MIR.
+This has two advantages.
+First of all, part (a) actually is already done and implemented in the Rust compiler!
+We *have* a complete and non-ambiguous definition of how Rust code is to be translated to MIR code.
+(Currently, this definition exists only in code; ideally, one day, it will also exist in natural language as part of a specification document.)
+As a second advantage, MIR is *much* simpler than Rust: It has way fewer operations, no syntactic sugar, less redundancy.
+(In fact, that's the entire reason why MIR was introduced into the compiler.)
+Specifying the behavior of a MIR program can concentrate on the parts that really matter, without focusing on details like how exactly a `for`-loop desugars into lower-level operations.
+
+Now, this is *not* to say that every Rust compiler has to use MIR in its compilation pipeline.
+It just means that the way I imagine a specification of Rust to look like is as consisting of two parts: The Rust-to-MIR translation, and a specification for MIR.
+If another compiler uses a different implementation strategy, it can still be compliant with the specification; it just has to ensure that Rust programs behave as specified.
+This is a common approach that can also be found, e.g., in the specification of CPU instruction sets: The specification describes the behavior of a complex instruction as a series of commands in some lower-level language. The CPU does not actually use that language as part of its implementation, but *it behaves as if it would*, and that's the only part that matters.
+**/Update**
projects / web.git / blobdiff