
Dafny: A Language and Program Verifier for Functional Correctness - kushti
http://research.microsoft.com/en-us/projects/dafny/
======
nickpsecurity
Good to see it show up on HN. It's a nice language and their rise4fun project
brings such stuff to a wider audience. I wonder if any readers with a lot of
hands-on experience in these can tell me how it compares to SPARK Ada. About
the same? Behind in capabilities? Ahead in some ways?

SPARK would seem to be the definitive baseline to compare all the others, too.

------
brudgers
Source:
[http://dafny.codeplex.com/SourceControl/latest](http://dafny.codeplex.com/SourceControl/latest)

------
cperkins
I like it. The Dafny annotations seem straightforward and approachable.

Anyone know of a similar system for Javascript?

------
whitten
Does anyone have an estimate to the difficulty of using Dafny as an annotation
to programs written in another programming language? I'm thinking of one on a
different OS (Linux) than the MS Windows OS for which Dafny appears to be
written.

------
SchizoDuckie
Eruhm

Is it just me, or is describing the functional correctness of a program with
another programming language asking for more problems?

~~~
wellpast
Not to me. I've found unit tests to be indispensable in establishing and
maintaining code correctness -- and my unit tests have always been written in
a PL, too.

~~~
lomnakkus
There are two cruical properties you want, I think:

A) It _must_ be possible to automatically and completely mechanically ensure
that implementation & proof don't get out of sync. Having a formal proof for
an algorithm which isn't the algorithm that you've actually ended up
implementing doesn't really help you one whit :). This is relatively simple
for unit tests and property-based tests like QuickCheck: Just observe that the
number of tests run actually increases over time and never decreases
unexpectedly. (Actually, it seems to be rather rare to have support from
Continuous Integration tools for tracking the latter.)

B) There must be (in some sense) at least some non-trivial difference between
the implementation & "proof". (At the absurd extreme: bisimulation doesn't
really work as proof of anything if the implementations are one and the same.)
For example, in Idris the implementation is basically just code while the
proof is the accomanying types -- which ensures that they're not basically
just saying the (trivially) same thing, even though the types greatly
_constrain_ what the implementation can do.

I think that the allure of "practical" dependent types (e.g. Idris) may be
that such languages trivially obey both properties. Of course you still end up
with a "trusted computing base" which is non-trivial in such cases.

