<br><div><br>On Sunday, January 11, 2015, Michael Hutchinson <<a href="mailto:mhutch@xamarin.com">mhutch@xamarin.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9 January 2015 at 16:32, Greg Young <<a href="javascript:;" onclick="_e(event, 'cvml', 'gregoryyoung1@gmail.com')">gregoryyoung1@gmail.com</a>> wrote:<br>
> It's not source analysis it theorem proving think formal proving a la eiffel<br>
<br>
The Code Contracts tools analyze (and rewrite) compiled code, but<br>
there's no reason why equivalent source analysis tools couldn't use a<br>
theorem prover.</blockquote><div><br></div><div>This is true it can work on any ast as of now it works on il. Previously it worked wih output from spec# and was called boogie. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> It's a massive!!!  task (like 5-10 man years) to bring it in as you need to<br>
> put contracts on all of the mono code<br>
><br>
> This is part of why it has not done well for Microsoft is much of the<br>
> framework lacks co tracts which makes the theorem prover very difficult to<br>
> use (needs tons of assume clauses)<br>
<br>
The repo includes the contract annotations for the BCL, and we have<br>
the reference source for much of the BCL too.</blockquote><div><br></div><div>Many of these are auto generated not manually written. They wrote a tool in msr to try to extract them. This also brings up an interesting question if mono intends to match every contract. It is also a higher level of coupling.</div><div><br></div><div>If I even use just a few libraries without contracts the contract prover is very annoying to use think about a call stack</div><div><br></div><div>Call: check preconditions-> post conditions -> returns v1</div><div>Call: no contracts param v1 returns v2 -></div><div>Call param v2 (how do you check preconditions?)</div><div><br></div><div>This gets worse when mutations are involved.</div><div><br></div><div>A big part of the reason the contracts library has not taken off is that huge portions of library code in the space doesn't have contracts associated with them. Also given the massive amounts of mutations that are happening good contracts are often hard to write. A good example of this would be stream.position post conditions after operations on a stream. Why it's a particularly nasty example is that much of the contract is relying on lower level code and assumes.</div><div><br></div><div>Don't get me wrong I love the idea of contracts. I am just pointing out that it's a massive amount of work to get contracts on vast portions of monos code base. If it's not pervasive then no one will use the contract proving as its really annoying.</div><div><br></div><div>Cheers,</div><div><br></div><div>Greg</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- m<br>
</blockquote></div><br><br>-- <br><div dir="ltr">Studying for the Turing test</div><br>