I believe the reasoning is that aerosol would have ultimately spread everywhere, including on the AC itself, while ballistics can be heavily influenced by airflow, but are still limited in range.
Reading through https://bazel.build/designs/skyframe.html, this sounds pretty much like what would be possible with the aforementioned recursive Nix and content-addressed paths. Bazel might still win in practice since the overhead of a Nix build is pretty high, which gets even more important when you do them recursively for each file.
You can convert a `String` into a `&'static str` using only safe stdlib functions via `Box::leak(s.into())`. This uses `unsafe` internally, of course... but so does almost any code.
Author of that project here, it's the other way around - I'm using the absence oft aliasing to turn mutable Rust code immutable, which I can then embed in Lean. But you're right that ownership (ie, affine types) per se doesn't help.
What would that abstraction look like? I really can't think of a more high-level abstraction of parallelism than a single method call saying "Please parallelize this sequential algorithm. But only when it makes sense."
What do you mean by "turning into"? I don't see much special syntax in the post apart from the general expression-oriented functional style, including higher-order functions. Which has always been part of Rust. If that means turning into Scala, then almost every high-level programming language is currently turning into Scala.
Aside from program synthesis, there is the more restricted form of code extraction, which turns definitions inside a theorem prover into code in a more traditional, runnable language such as OCaml. But you'll still want to do one or more refinement steps inside the theorem prover where you turn your spec into more efficient definitions (or even definitions that are computable at all - how do you evaluate an unbounded universal quantifier?)
But widgets do have the same type: Widget, which the author already uses as a trait object. I think he was getting confused by mixing &Widget and Rc<RefCell<Widget>>. Just declare a type alias for the latter, use it everywhere, and it should work. You would do the about the same thing in C++, I believe.
I actually started the project in Isabelle: https://github.com/Kha/electrolysis/tree/isabelle/thys. Automation was nice, translating Rust traits not so much. You really want them to be type classes, which Isabelle only supports for the single-parametric case.
As of right now, the project would probably be easier in Coq. But I'm confident that Lean 3 will eventually feature more powerful automation (and no Ltac). It is, after all, being developed by Leonardo de Moura, one of the creators of Z3.
I have heard of it, it features a nice application of Separation Logic. Though not needing that kind of logic at all does feel even better!
There is also an extension of an extension of CFML to asymptotic complexity analysis, after which I may model my own analysis: http://gallium.inria.fr/blog/formally-verified-complexity-wi...
Well, that change would also break the proof in general :) . But I see your point.
I've written about overflow checking some more below, but what you'd really want for that is some solid support of subtypes or refinement types - it's not just integers that have to become bounded, but also most data structures. Lean isn't quite there yet, unfortunately, but this should change in the near future with its new focus on powerful automation.
