mirror of
https://github.com/achlipala/frap.git
synced 2024-11-27 23:06:20 +00:00
Placeholder introduction
This commit is contained in:
parent
71d8c98936
commit
2d64f99796
2 changed files with 15 additions and 0 deletions
1
Makefile
1
Makefile
|
@ -1,2 +1,3 @@
|
|||
frap.pdf: frap.tex
|
||||
pdflatex frap
|
||||
pdflatex frap
|
||||
|
|
14
frap.tex
14
frap.tex
|
@ -71,6 +71,20 @@ The license text is available at:
|
|||
|
||||
\mainmatter
|
||||
|
||||
\chapter{Why Prove the Correctness of Programs?}
|
||||
|
||||
The classic engineering disciplines all have their standard mathematical techniques that are applied to the design of any artifact, before it is deployed, to gain confidence abouts its safety, suitability for some purpose, and so on.
|
||||
The engineers in a discipline more or less agree on what are ``the rules'' to be followed in vetting a design.
|
||||
Those rules are specified with a high degree of rigor, so that it isn't a matter of opinion whether a design is safe.
|
||||
Why doesn't software engineering have a corresponding agreed-upon standard, whereby programmers convince themselves that their systems are safe, secure, and correct?
|
||||
The concepts and tools may not quite be ready yet for broad adoption, but they have been under deveopment for decades.
|
||||
This book introduces one particular tool and a body of ideas for how to apply it to different tasks in program proof.
|
||||
|
||||
As this document is in a very early draft stage, no more will be said here, in favor of jumping right into the technical material.
|
||||
Eventually, there will no doubt be some sort of historical overview here, as part of a general placing-in-context of the particular approach that will come next.
|
||||
There will also be plenty of scholarly citations (here and throughout the book).
|
||||
In this early version, you get to take the author's word for it that we are about to learn a promising approach!
|
||||
|
||||
\appendix
|
||||
|
||||
\backmatter
|
||||
|
|
Loading…
Reference in a new issue