Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!rodan.acs.syr.edu!wotan.top.cis.syr.edu!greeny
From: greeny@wotan.top.cis.syr.edu (Jonathan Greenfield)
Newsgroups: comp.sys.transputer
Subject: Re: producers and consumers
Message-ID: <1991Feb13.160731.20859@rodan.acs.syr.edu>
Date: 13 Feb 91 21:54:11 GMT
References: <17289.9102131102@prg.oxford.ac.uk>
Reply-To: greeny@top.cis.syr.edu (Jonathan Greenfield)
Organization: CIS Dept., Syracuse University
Lines: 52

In article <17289.9102131102@prg.oxford.ac.uk> HALLAM@physics.oxford.ac.uk ("Phillip M. Hallam-Baker") writes:

>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.

Just an incidental--I based my comments on Hoare's definition of CSP in his
book of the same name.

>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...'

Well, this was merely my point in the first place--that CSP is a fine
theoretical entity, but that it should not be considered a programming
language.  My whole point was that if we consider CSP processes to be
programs, then we run into a problem.  Since some have suggested that CSP
processes are programs, I figured that either I or Hoare had a conceptual
problem with CSP...

>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

Again, the *traces* of a process is merely an alternate description of (what
I referred to in a previous posting as) the language of events for a process.


If you are correct that CSP was not intended by Hoare as a programming 
language, then no problem exists (to my knowledge).  We merely recognize CSP 
processes to be mathematical descriptions of automata, but not programs.

As I do not research this area, either (and as I do not work as a 
theoretician), I am glad to see that my insights into CSP have been somewhat
validated by your posting.


Jonathan