derkha

No, comparator does check the entire closure

The tower was built after Brahe's death https://www.rundetaarn.dk/en/article/tycho-brahe-was-not-her...

Insignificant consequences. https://www.fiercehealthcare.com/hospitals/how-many-employee...

Lean 4 developer here. If the array is shared, we make a full copy. It's the same semantics as in Swift.

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.

They probably mean "red-yellow", which is an intermediate "wait for it" state in many European countries, including Germany https://de.wikipedia.org/wiki/Ampel#/media/Datei:Traffic_lig...

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.

I prefer the simplicity of https://github.com/firecat53/networkmanager-dmenu, which works fine under sway

Implementation on Github: https://github.com/microsoft/mimalloc

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.

Yes, that is a valid alternative encoding: https://en.wikipedia.org/wiki/Church_encoding#Represent_the_...

In general, what you describe is representing an inductive type by its _eliminator_: https://www.quora.com/In-type-theory-what-is-an-eliminator-a...

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.

> 1.16699016 × 10-8 hertz

IOW, once every 2.7 years. Google Calculator is genius.

Nice, this may make me finally move on from irssi

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.

By calling the verification 'simple' myself, I concede that it may also be _simplistic_ in parts. Perhaps I should have emphasized that this project is mostly about algorithmic correctness currently. A bug in the compiler backend would not be a bug in the algorithm, and neither would I call a function unexpectedly panicking on more than 2^63 elements an algorithmic bug. And if you compile your Rust program with overflow checks (default in debug mode), the verification can still guarantee partial correctness: If it does not panic due to some overflow, the result is correct.

You're correct in that what I'm constructing is some form of Dynamic Single Assignment. But together with the eradication of mutable references (and perhaps other effects in the future), it felt better to me to describe the transformation from the purity aspect.

There is a PR for a Lean backend producing both C++ and Rust: https://github.com/leanprover/lean/pull/1090 Note, however, that this is purely focused on executing Lean code, not integrating with other C++/Rust sources.

Even the EU seems to think so: http://www.reuters.com/article/us-turkey-security-eu-hahn-id...

To clarify Bahamut's point: The functions must be analytic - https://en.wikipedia.org/wiki/Analytic_continuation#Initial_.... Regardless of the actual value of foo, at least one of g or h won't be differentiable at foo, so they can't both be analytic (assuming you choose some open superset of N u {foo}, otherwise the theorem breaks down even sooner).