Processes against tests: On defining contextual equivalences

In this paper, we would like to offer and defend a template to study equivalences between programs-in the particular framework of process algebras for concurrent computation. We believe that our layered model of development will clarify the distinction that is too often left implicit between the tasks and duties of the programmer and of the tester. It will also enlighten pre-existing issues that have been running across process algebras such as the calculus of communicating systems, the pi-calculus-also in its distributed version- or mobile ambients. Our distinction starts by subdividing the notion of process in three conceptually separated entities, that we call process terms, (completed) processes and tests, and by stressing the importance of formalizing the completion of process terms and the instrumentation that results from placing a (completed) process into a test. While the role of what can be observed and the subtleties in the definitions of congruences have been intensively studied, the fact that not every term can be tested, and that the tester should have access to a different set of tools than the programmer is curiously left out, or at least not often formally discussed-in this respect, the theory of monitor is a counter-example that we discuss and compare to our approach. We argue that this blind spot comes from the under-specification of contexts-environments in which comparisons occur-that play multiple distinct roles but are generally-at least, on the surface of it-given only one definition that fails to capture all of their aspects. (C) 2022 Elsevier Inc. All rights reserved.

Automated summary

This paper proposes a model for studying program equivalences within the framework of process algebras for concurrent computation. The model divides the notion of process into process terms, (completed) processes, and tests, emphasizing the importance of formalizing the completion of process terms and the instrumentation of placing a (completed) process into a test. The paper highlights the distinction between the tasks of programmers and testers, and addresses pre-existing issues in process algebras.