Zig is also very compiler dependent, but at least the language has direct enough translation as a goal, that it's straightforward to learn the semantics from trial and error alone.
It wasn't standardized until 1989 - 17 years later!
I think Rust will do just fine, and the compiler error message is (IMO) the best of any language, making adhoc exploration possible.
Can you imagine trying to explore C from ad-hoc alone based on its compiler errors?!
It’s in many ways similar to the way the early web was developed, different browsers tried out many different additions, copied the better ones and improved them. The standardisation process we now have didn’t exist back then, and has been through a number of iterations itself since (the “xml every thing” process that ended with xhtml had a questionable outcome at best).
Some may argue that a formal standardisation process should have started earlier, before IE became too dominant. But I’m not too sure, IE was incredibly innovative and introduced some important technologies and apis, before stagnating.
In fact the “modern” html/css/js standardisation process is specifically lead by individual browsers implementing and trying out new additions, with formal acceptance dependent on other browsers also implementing it. It’s inherently a implementation lead standardisation process, not necessarily committee led.
Rust has the goal of putting as much smartness between what you type and what the compiler produces, which is a perfectly fine goal, but without a specification for the input semantics it's a pretty wobbly thing, especially for a systems programming language. A lot of bit packing code is simply not writable in rust today without immediately invoking UB, that works for now but might break with every bugfix release.
At about the time K&R1 was published, the Ritchie's original C compiler was being replaced by pcc, and `lint` was another early (diagnostics-only) implementation. The K&R1 reference manual includes a few mentions of features that were deprecated by pcc, or new in pcc.
So I think C was more mature than "the compiler is the specification" by the end of the 1970s.
> It wasn't standardized until 1989 - 17 years later!
> I think Rust will do just fine,
Not based on the example you gave - using the behaviour of a single C compiler as a specification for the language implemented by that fairly easy due to how small C is. Rust is very much larger than C.
> and the compiler error message is (IMO) the best of any language, making adhoc exploration possible.
> Can you imagine trying to explore C from ad-hoc alone based on its compiler errors?!
Not much different from Rust: Gcc and clang C compiler errors are exceptionally good, and I miss them terribly when programming in some other language (like C++, or Javascript).
I wish i still had my late 80s copy.
Not mainstream language 'fine', but fine.
But what is interesting I think is that if miniRust is successful (or even if it isn't) zig can learn lessons on how to do borrow checking on zir: even if it isn't part of the official language release it could be a useful tool for ci/linting/touchup, especially if it becomes an "anointed" tool
Is there any way to have Zig output a flat binary? I am looking for a higher level FlatAssembler. [0]
It's not "useful" in the sense of being something that you'd actually run.
This is a start on the lowest layer of the description, describing the "abstract machine" that runs Rust programs; it assumes that all borrow-checking and type-checking has already been done, generics have been expanded, and so on.
The other two big pieces that will need doing are properly describing the type system, and properly describing how the high-level features that aren't strictly necessary can be "lowered" into simpler forms.
In the last year there's been some real work on the first of those under the name "A MIR Formality": https://nikomatsakis.github.io/a-mir-formality/docs/intro
Maybe the existing Rust Reference will turn into the second.
What if we could actually run it (stay with me for a second) with a well known interpreter such as python3 or v8?
That is the direction py2many has taken. Trying to define a small subset of python + missing rust features (pattern matching as an expression), interfacing with formal verification methods such as z3 and then finally building a transpiler to transpile this language to rust.
If you are writing a Rust compiler or a Rust verification tool, then a spec like MiniRust is a key part of telling you whether you got it right.
If you are not doing either of these things then you probably don't have a use-case for MiniRust. :)
lol, I didn't even realize the wrong associations I would create here. Glad you liked it anyway. :)
I guess my choice of name was not great. I also considered pseudo-MIR but that didn't really capture it, either. And "formally specified fragment of Rust" isn't very catchy.^^ "CoreRust", maybe it should have been "CoreRust"...
I'd personally pretty much always expect "mini" or "r" (as in "rperl", a restricted subset of Perl with C++ connections) versions of a language to be restricted subsets for some purpose (rperl's is to give away flexibility for performance while maintaining a good portion of the original language).
I've seen an "e" or "emb" prefix or a "small", "tiny", "micro" or "µ" (or "u") prefix to mean a small toolchain version several places, like SmallC or uclibc or Mikroe's mikroC (https://www.mikroe.com/mikroc). It wouldn't surprise me to see a "nano" version of a language tool either. Sometimes these are subsets as well, but to fit the size constraints of the target rather than for constraining the input for its own sake.
Cool bear has breached containment.
I do have to admit I love the recent-ish trend of including dialogues in blog posts. Plato would be proud.
"MiniRust is the cornerstone of my vision for a normative specification of Rust semantics. It is an idealized MIR-like language with the purpose of serving as a "core language" of Rust. This is part of a larger story whose goal is to precisely specify the operational behavior of Rust, i.e., the possible behaviors that a Rust program might have when being executed: the behavior of a Rust program is defined by first translating it to MiniRust (which is outside the scope of this repository), and then considering the possible behaviors of the MiniRust program as specified in this document. That translation does a lot of work; for example, traits and pattern matching are basically gone on the level of MiniRust. On the other hand, MiniRust is concerned a lot with details such as the exact evaluation order, data representations, and precisely what is and is not Undefined Behavior."
It is yet another step on the path to having a Rust specification, especially with respect to precisely specifying the capabilities and requirements of `unsafe` code.
The two projects are related, but have different objectives (mir-formality includes traits and borrow checking, while MiniRust focuses on operational semantics).
[1]: Living with the Rust trademark [LWN.net] https://lwn.net/Articles/901816/
Not only that the spec will be clearer but you can get more contributors on the core part of Rust.
