Abstract

this report may apply, should support following activities: 1. formulation of a requirement (e.g., total correctness statement, or algebraic specification, or process logic formula), 2. description of a construction (e.g. resp., imperative program, or algebra, or process), 3. verification that a given construction satisfies a given requirement. The verification step 3 above cannot, for any realistic classes of requirements and constructions, be fully automated. Therefore, it generates a proof obligation that may be either proven by hand, or passed over to a heuristic theorem prover, or left unproven but recorded in the construction's documentation for future reference, in case something goes wrong. But then, it is acceptable that the steps 1 and 2 generate proof obligations as well. For instance, an attempt to automatically type check a construction might break down at some point, in which case the type checker would generate a proof obligation for that point and then proceed as if everything worked well. It is important that the number and the complexity of generated proof obligations be kept within reasonable limits. In particular, no proof obligations should be generated where no dependent types and no subtypes are involved. This report presents a simple but powerful language SDDP

Citations