An axiomatic basis for computer programming
Communications of the ACM
Separation Logic: A Logic for Shared Mutable Data Structures
LICS '02 Proceedings of the 17th Annual IEEE Symposium on Logic in Computer Science
The rewriting logic semantics project: a progress report
FCT'11 Proceedings of the 18th international conference on Fundamentals of computation theory
An executable formal semantics of C with applications
POPL '12 Proceedings of the 39th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Towards a unified theory of operational and axiomatic semantics
ICALP'12 Proceedings of the 39th international colloquium conference on Automata, Languages, and Programming - Volume Part II
Checking reachability using matching logic
Proceedings of the ACM international conference on Object oriented programming systems languages and applications
WRLA'12 Proceedings of the 9th international conference on Rewriting Logic and Its Applications
Making maude definitions more interactive
WRLA'12 Proceedings of the 9th international conference on Rewriting Logic and Its Applications
Automatic inference of specifications using matching logic
PEPM '13 Proceedings of the ACM SIGPLAN 2013 workshop on Partial evaluation and program manipulation
The rewriting logic semantics project: A progress report
Information and Computation
Hi-index | 0.00 |
Matching logic is a new program verification logic, which builds upon operational semantics. Matching logic specifications are constrained symbolic program configurations, called patterns, which can be matched by concrete configurations. By building upon an operational semantics of the language and allowing specifications to directly refer to the structure of the configuration, matching logic has at least three benefits: (1) One's familiarity with the formalism reduces to one's familiarity with the operational semantics of the language, that is, with the language itself; (2) The verification process proceeds the same way as the program execution, making debugging failed proof attempts manageable because one can always see the "current configuration" and "what went wrong', same like in a debugger; and (3) Nothing is lost in translation, that is, there is no gap between the language itself and its verifier. Moreover, direct access to the structure of the configuration facilitates defining subpatterns that one may reason about, such as disjoint lists or trees in the heap, as well as supporting framing in various components of the configuration at no additional costs.