
KRust: A Formal Executable Semantics of Rust - dmmalam
https://arxiv.org/abs/1804.10806
======
kibwen
At the recent Rust All-Hands in Berlin a few groups of researchers
independently working on verifying Rust's semantics decided to form a working
group to focus their efforts (see the official announcement at
[https://internals.rust-lang.org/t/announcing-the-formal-
veri...](https://internals.rust-lang.org/t/announcing-the-formal-verification-
working-group/7240) ). I don't recognize any of the names on this paper from
there, so it looks like there may be even more people working on this than we
thought, and if that also happens to encompass anyone reading this comment,
feel free to reach out to the working group. :)

Regarding the OP, I'll quote a comment from reddit:
[https://www.reddit.com/r/rust/comments/8g6mam/krust_a_formal...](https://www.reddit.com/r/rust/comments/8g6mam/krust_a_formal_executable_semantics_of_rust/)

 _" It looks like they wrote an interpreter for a small subset of Rust in a
particular formal system. But the subset is extremely small, and it doesn't
look like they derived any novel results from this. The examples they give, of
proving the running time of a GCD algorithm, would work in pretty much any
procedural language; it's pretty much just a syntax modification away from the
same example in any language.

They implement a very simple model of borrow checking, but their subset
doesn't seem to support references in type signatures, so it doesn't seem like
they can even model any inter-procedural effects of the borrow checker, just
some purely local restrictions on aliasing.

I suppose that this is a good first step if you want to write a formal
semantics of Rust in 𝕂, but it seems like there's not really enough here yet
to be of interest."_

~~~
still_grokking
> "I suppose that this is a good first step if you want to write a formal
> semantics of Rust in 𝕂, but it seems like there's not really enough here yet
> to be of interest."

I thing the work is interesting.

It would be a great endeavor to model the whole language so you need people to
help with that. But how would one know that someone has started a project like
that if they don't publish something about it?

In my opinion the whole story about only accepting "novel" and "readily
applicable" results in academia isn't quite helpful. A "Publish early, publish
often" strategy could produce more and better results in the long term I
think.

If a result isn't useful or novel on it's own that's no issue imo. It can
still become an important building block of some later innovation! Reusable
work done is work done, indifferently of it's "novelty" or direct
applicability.

Also the 𝕂 Framework is amazing for formal reasoning about languages so this
work is indeed an important first step.

~~~
tom_mellior
> A "Publish early, publish often" strategy could produce more and better
> results in the long term I think.

That (at least the "publish early" part) is already the case for a lot of
programming language research in things like semantics or program analysis.
Published papers often treat a toy language (no arrays, no dynamic memory
allocation, etc.) and leave the rest for "future work". Sometimes that future
work does materialize, often it doesn't.

It's a difficult situation for academia: If the basic system is too hard to
extend to a full language, you will end up without final results, and from the
point of view of your funders you have just wasted a lot of time and money. If
it's too easy to extend to a realistic language, you might build a tool but
end up doing "only engineering" without having new breakthroughs to publish,
again seen in academia as wasting research funds.

For many people in academia, the incentives for building systems _really_
applicable to real-world languages are just not there.

~~~
adrianN
It's a long, hard way from a research prototype to something that works on a
machine different from the author's laptop. It's unclear whether paying
researchers to build actual products makes sense. If there is a clear market
for the application, there is always the possibility to start a spin-off
company.

~~~
tom_mellior
Sure, but there are many many useful tools for which there is no clear market.
I do think academic institutions should do more to value and promote
development of useful artifacts. But that's difficult to do if rankings (of
people and of institutions) are only based on academic publications, which
(for the most part) don't include tool descriptions.

------
nickpsecurity
This is the same underlying tool that powers KCC and RVMatch.

[https://github.com/kframework/c-semantics](https://github.com/kframework/c-semantics)

[https://runtimeverification.com/match/](https://runtimeverification.com/match/)

Exactly what I’d hoped someone would do. Well, the first step anyway. The
second step was doing a Rust semantics in terms of the C semantics already
done. That allows quite a few things like Rust-to-C compilers, defeating
Karger-Thompson attack, and potentially verification of interactions of Rust
and C FFI code. On my end down the line, also use of C tooling for
verification of equivalent Rust code.

------
mlazos
This is awesome. It also makes me really excited that finally there's a
language that's catching on (I consider Haskell, OCaml and the like to be
niche) where the subset of the language that is used for a formal semantics is
very similar to the language being modeled. I feel like with Javascript, C and
other similar languages the core language that is used in a formal semantics
has to "patch up" all of the unsafe holes in their respective type systems,
and as a result the core language ends up looking a lot different from the
language it is intended to model.

~~~
platinumrad
I wouldn't be surprised if the total number of Rust programmers is smaller
than the total number of Haskell or OCaml programmers. The latter two are
frequently taught in school, unlike Rust.

~~~
lambda
Rust is increasingly frequently taught in schools; and when Haskell or OCaml
are taught in schools, it's usually as part of a "programming languages"
survey course where you learn a little bit of a few languages of different
paradigms, and I expect that most students won't really retain much from the
class a year or two later unless it helped them develop an independent
interest in functional programming.

~~~
jononor
Can you link to one or two classes taught in Rust?

It is surprising to me, since academia often trails by many years.

~~~
iuppiter
[http://cis198-2016s.github.io/](http://cis198-2016s.github.io/)

~~~
jononor
Not taught since fall 2016. Was taught by some passionate students it looks
like.

Only current one I could find is
[https://www.mccormick.northwestern.edu/eecs/courses/descript...](https://www.mccormick.northwestern.edu/eecs/courses/descriptions/396-496-9.html)

------
iuppiter
I am the author of this paper. The semantics is far from complete and I am
still working it. It is not a easy to formalize Rust completely. KRust is now
just very very small step towards that. It may be not "useful" currently, but
I think there will be a complete one if more people work on this.

~~~
tom_mellior
As a small but I think important remark, the statement in the abstract that
you tested on the "official Rust test suite" is very misleading. As the text
later makes clear, you tested on a small fragment of it. That is good, that is
important, and you should continue doing it.

But as phrased in the abstract, I first though that you pass all of the Rust
tests, or at least a significant majority of them. If I were a reviewer of
this paper, I would complain about this loudly, including to the PC
chair/editor. As a fellow researcher, I urge you to change this wording in the
abstract to something less misleading.

~~~
iuppiter
Thank you for pointing it out. I just used all the codes in the official test
suite to test KRust, but it only passed a small fragment.

