Paper Details

Communicating Process Architectures (CPA)
 Title: Why is CSP Needlessly Difficult to Learn and so Easy to Forget, and Why are its Semantics Upside Down?
 Conference: Communicating Process Architectures 2014
 Authors: Peter H. Welch
School of Computing, University of Kent
There has been a gap between the ways CSP and occam developed that's troubled me for a long time. My problem is that I think "occam" and that leads me to make mistakes in "CSP". Of course, my answer is that CSP must be doing it wrong and needs fixing. And, of course, I am probably very wrong!

Nevertheless, I shall attempt to explain my difficulties with CSP, with respect to simplicity, programming concepts and an old-fashioned (but arguably more natural) view of semantics.

Outline of Difficulties
  - CSP has two operators for sequence ("-->" and ";") whereas occam has one ("SEQ"). CSP needs this because events are not processes. If they were (as in occam), simplifications follow.
  - The single global space of event names in CSP requires a hiding operator ("\"). This is so that networks can be constructed whose processes privately synchronise – but they have to be built with global events that are hidden post-construction. This causes problems – e.g. for recursively defined networks. In occam, name spaces follow traditional block structure. Networks with internal synchronisations do not use global events that must be hidden later. This is a simpler idea and avoids the problems mentioned.
  - In CSP, channel arrays are identical to a single channel carrying the index with the message. This is odd as they describe rather different things.
  - Complex events – e.g. d?x?y!f(x,y) – are more complex and less general than the two-way, or session, protocols proposed for occam-pi. The lack of direction specification for their components leads to unnecessary mistakes. This also applies to simple events, when those events are channel messages.
  - Modern CSP forsook the original idea (in Hoare's CSP) of associating event alphabets with processes. Instead, they are associated with a range of parallel operators. I think this is so as to give flexibility, when building networks, for specifying whether processes synchronise on events or interleave on them. The downside is that alphabets are not constructed once for each process; they have to be constructed each time each process is combined in parallel with another and each time any combinations are combined. Getting all these alphabets correct can become complex quite quickly, leading to a tyranny of alphabets.
  - occam alphabets are derived automatically and associated with processes. There is only one parallel operator ("PAR") and it is trivially associative and commutative. Associativity does not come easy for the parallel operators of modern CSP. occam-pi enables great flexibility for processes to declare whether they synchronise or interleave on events. CSP could do the same, with gains in simplicity. It also seems more natural for the process designer, rather than process user, to specify these things.
  - Finally, why does the semantics encourage design by starting from too much behaviour and then cutting it down, by refinement, to what is wanted. Everything refines CHAOS, but that's not a good place to start. Most programmers – well, me anyway – like to build behaviour incrementally. Start from bottom, the process with no behaviour (STOP), and then add – don't cut!

Discuss the merits of the above. Formalise it (if worthy) into a new syntax for CSP. Produce useful examples comparing the current syntax with the proposed. Consider the semantic issues. Propose further work.  

BibTeX Entry

Full paper

Full paper