Dafny: Verification-Aware Programming Language
Posted by handfuloflight 9 hours ago
Comments
Comment by sriku 6 hours ago
Try writing a^b in integers and proving its correctness. The simple version works (based on a x a^(b-1)). But if you write an "optimised one" using (with handwaved details) (a^(b/2))^2 .... pulled some serious hair trying to prove this function works.
Comment by sriku 6 hours ago
Comment by mikiskk 4 hours ago
https://glados-michigan.github.io/verification-class/fall202...
Comment by skybrian 46 minutes ago
Fine for teaching, but it doesn't seem to be a suitable tool to generate idiomatic library code?
Comment by fooker 7 hours ago
Comment by porcoda 6 hours ago
Comment by fooker 4 hours ago
As for being not expressive enough for specifications, isn't the code itself a form of specification? :)
Comment by cake-rusk 2 hours ago
Comment by ashton314 6 hours ago
Good question. This is the holy grail. This is what everyone in PL research would love. This is where we want to get to.
Turns out a language as “simple” as C has sufficiently complicated semantics as to limit rigorous analysis to the basics. One example is loop analysis: it’s very useful to know that a loop will terminate eventually; if a loop is modifying some state and—worse—if the iteration variable gets modified—kiss your analysis goodbye because mechanically synthesizing strong pre- and post-conditions becomes insurmountable. It’s not an engineering challenge. It’s a math/pure CS theory challenge.
Comment by fooker 4 hours ago
I assume if you were to develop such a system for C, C++, or Rust you'd similarly expect the user to do this.
Comment by ashton314 2 hours ago
(Any experts on formal verification please correct any inaccuracies in what I say here.)
The upshot of it is that C, C++, and Rust permit too much behavior that isn’t capturable in the type system. Thus, the properties that you’re interested in are semantic (as opposed to syntactic; type systems turn semantic properties into syntactic ones) so Rice’s theorem applies and there’s no computable way to do the analysis right.
Comment by quamserena 6 hours ago
Comment by fooker 4 hours ago
I'd have assumed, by virtue of being Turing complete, you could express any invariant in almost any language?
Comment by wavemode 15 minutes ago
For example a NonNegativeInteger type in most languages would just have a constructor that raises an exception if provided with a negative number. But in languages with proofs, the compiler can prevent you from constructing values of this type at all unless you have a corresponding proof that the value can't be negative (for example, the value is a result of squaring a real number).
Comment by voxl 6 hours ago
Comment by nextos 6 hours ago
Dafny can compile to and interface with a few languages, including C#.
Comment by fooker 4 hours ago
Are there benchmarks showing dafny is faster than other inefficient options ?
Comment by hatefulmoron 3 hours ago
I'm not sure about benchmarks comparing languages, but Dafny goes through a lot of tweaking to make the process faster.
Comment by fjfaase 7 hours ago
Comment by algorithmsRcool 6 hours ago
Comment by dionian 8 hours ago
Comment by ted_dunning 7 hours ago
You could add Scala as a compilation target or you could just use the Java output and call formally verified Java functions from Scala. Even if you do get an implementation that produces Scala, don't expect the full power of idiomatic Scala to be available in the code you formally verify. To verify code, you have to write the code in Dafny with associated assertions to be proven. Since there are multiple compilation targets multiple formal constraints on what can usefully be verified, the data types available will not match the data types that you would use natively from Scala.
Comment by gz09 7 hours ago
Comment by ted_dunning 6 hours ago
That means that most of the proof can be done ahead of time with just some loose ends verified using an SMT prover at runtime.
Comment by esafak 3 hours ago