Pipe-calculus: Difference between revisions

Line 311: Line 311:
Pipe-calculus fits into this framework if we make the following observations.
Pipe-calculus fits into this framework if we make the following observations.


* Actions are the atomic units of behavior.
* Prefixes are atomic units of behavior (actions).
* Actions with sequential and alternative composition form basic process algebra (BPA). <ref name="Fokkink">
* Prefixes with sequential composition and choice form basic process algebra (BPA). <ref name="Fokkink">
Wan Fokkink: [https://www.cs.vu.nl/~wanf/BOOKS/procalg.pdf Introduction to Process Algebra], Springer-Verlag
Wan Fokkink: [https://www.cs.vu.nl/~wanf/BOOKS/procalg.pdf Introduction to Process Algebra], Springer-Verlag
</ref>
</ref>
Line 319: Line 319:
There are also notable differences.
There are also notable differences.


* Communication primitives in mainstream process calculi often inseparably unite two conceptual steps: the selection of a communication channel and the act of message sending. For example [[wikipedia:pi-calculus|Π-calculus]] <ref> Joachim Parrow: [https://courses.cs.vt.edu/~cs5204/fall05-kafura/Papers/PICalculus/parrow~2.pdf An Introduction to the Π-Calculus], chapter to appear in Handbook of Process Algebra, ed. Bergstra, Ponse and Smolka,
* The most outstanding difference is the lack of channels. Pipe-calculus processes only have a conceptual input and output, however one can simulate channels with synchronisation where atoms stand for channel names.
Elsevier</ref> defines ''input prefixing'' <math>c\left(x\right).P</math> and ''output prefixing'' <math>\overline{c} \langle y \rangle.P</math> to denote receiving a name via channel <math>c</math> and sending a name via channel <math>c</math> respectively, before proceeding as <math>P</math>. Although one can introduce as a convention '''synchronization''' where the communicated message is ignored, and '''broadcast''' where a group of processes are receiving messages on the same channel. In pipe-calculus these steps are separated by design.
* Communication primitives in mainstream process calculi often inseparably unite two conceptual steps: the selection of a communication channel and the act of message sending. For example [[wikipedia:pi-calculus|Π-calculus]] <ref> Joachim Parrow: [https://courses.cs.vt.edu/~cs5204/fall05-kafura/Papers/PICalculus/parrow~2.pdf An Introduction to the π-Calculus], chapter to appear in Handbook of Process Algebra, ed. Bergstra, Ponse and Smolka,
Elsevier</ref> defines ''input prefixing'' <math>c\left(x\right).P</math> and ''output prefixing'' <math>\overline{c} \langle y \rangle.P</math> to denote receiving a name via channel <math>c</math> and sending a name via channel <math>c</math> respectively, before proceeding as <math>P</math>. Although one can introduce as convention '''synchronization''' where the communicated message is ignored, and '''broadcast''' where a group of processes are receiving messages on the same channel. In pipe-calculus these steps are separated by design.
* In pipe-calculus there is no counterpart of '''hiding''' that prevents interference between two groups of processes that are using the same channel name for communication. Since there is no general, bidirectional parallel composition, we don't need a hiding primitive. The pipe operation naturally restricts communication to a pipeline.
* In pipe-calculus there is no counterpart of '''hiding''' that prevents interference between two groups of processes that are using the same channel name for communication. Since there is no general, bidirectional parallel composition, we don't need a hiding primitive. The pipe operation naturally restricts communication to a pipeline.
* In pipe-calculus, if a process fails to synchronize, it is aborted. This is different from the usual implementation where a process that fails to synchronize does not evolve, it keeps "waiting" for a message, opening up the possibility for asynchronous communication.
* In pipe-calculus, if a process fails to synchronize, it is aborted. This is different from the usual implementation where a process that fails to synchronize does not evolve, it "keeps waiting" for a message, opening up the possibility for asynchronous communication.


== Extensions ==
== Extensions ==
283

edits