From: Ralf Jung Date: Wed, 7 Jun 2017 20:32:34 +0000 (-0700) Subject: expand on the MIR-spec part X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/fa00d89780c6a7e2add6a860b05fd3a0997b3e77 expand on the MIR-spec part --- diff --git a/personal/_posts/2017-05-23-internship-starting.md b/personal/_posts/2017-05-23-internship-starting.md index 54361c2..7a4eea0 100644 --- a/personal/_posts/2017-05-23-internship-starting.md +++ b/personal/_posts/2017-05-23-internship-starting.md @@ -36,3 +36,18 @@ What exactly do the guarantees "mutable borrows don't have aliases" and "the poi That's it for now. I don't have the answers to these questions, but hopefully my work will help getting closer to an answer. I will keep you posted on my progress (or lack thereof), probably on a weekly or bi-weekly basis. + +**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.