🚀 go-pugleaf

Jonathan Greenfield writes :-

>>>>>>
If event1 is an input event, say

   event1 = c.v = c?v

and
  
   A = c?v -> SKIP

then what does "execution" of A mean?  Hoare says that process A is initially
prepared to engage in event c.v.  Since it seems to me that an input event can
not be considered to have "occurred" when taken in isolation (as in process
A, which is not composed with any other processes), I cannot interpret the
statement that a process is "prepared to engage in" an event to mean that the
event "occurs."
 <<<<<<<<<

Although I am by no means a CSP person I suspect that the problem here is
lack of clarity and a confusion between different CSP models.

The original CSP notation does not have a concept of an `input event' or
output event. There are simply events. The input and output notation is part
of a collection of notational clutter that various persons have added to
CSP over the years.

There are very good reasons why the process

A = event -> B

is interpreted as `A is prepared to engage in event' and not `A performs
event'. If the latter interpretation were allowed then the hierarchy of
processes would not work. The parallel operator || is a binary operator
which takes as it's arguments two processes and returns a single process.
(Think of this as algebra not as executing a computer program). The symetry of
the whole is lost if you take the `performs' interpretation since if you have
the process `A||C' where C=STOP{with alphabet {event}} then the composite
process will behave as STOP -- making a complete nonsense of the idea of
the interpretation of A as `A performs...'

To interpret a CSP process and how it will behave it is necessary to look
at it's *traces*. The function tr (in dark squigly type) takes a process
as it's argument and returns the set of all possible behavious of the process

Unfortunately the CSP book does not seem to give as much attention to traces
as they deserve. I suspect because at the time the book was written the
traces model was considered of theoretical interest rather than of practical
interest.

The input and output notation is a bolt on accessory which may be retrofitted t 
to almost any brand of CSP. It is simply another method of expressing the
alphabet of a process. Basicaly the idea is that if your network is 
triple-disjoint (all communication is between pairs of processes) then you
can dispense with the tedium of defining an alphabet for each process.
The business of input and output is another layer of fancy stuff again
- basicaly it allows you to consider the notion of processes having state
apart form that directly concerning communication. 

The input and output bit is not the only solution to the `problem' of the 
alphabets the alternative, as used in Bill Roscoes timmed CSP and in most
of the probabalistic model I have seen is to bind the alphabets to the 
parallel operator. - ie :

		A || B
		 a    b

where a and b are alphabets (no greek characters in email sob !)

This was used in the untimed CSP model at one time. I don't like it as it
makes hierachies of processes a pain. Also real systems with lots of processes
start to look horrible. However those who are prepared to brave the horrors
of contraction mappings on ultra metric spaces (or something like that) are
allowed a few notational idiosyncrasies.... (That should do -- hopefully
someone at the PRG will now explain why it makes everything lovely and simple!)

Anyway my point is that CSP does not contain a conceptual problem 
as Mr Green suggests. The whole point of CSP is that parallel processes
*are* conceptual problems. CSP is merely a tool to help understand some of
them.

Phillip M. Hallam-Baker

Discaimer : The usual. Plus the fact that I don't research in this area and
	so anything I say is no more likely to be correct as the next person.
	Still since most of the point of science is trying to express yourself
	if I have misrepresented anyone elses views its their own fault for
	not explaining them better in the first place.