Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!psuvax1!rutgers!cmcl2!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: Anarchic protocol ANY (occam2)
Message-ID: <1991May22.112448.22321@rodan.acs.syr.edu>
Date: 22 May 91 17:59:21 GMT
References: <9105152020.AA15174@theory.TN.CORNELL.EDU> <LLW.91May17095750@corwin.eng.yale.edu> <1758@culhua.prg.ox.ac.uk> <1991May20.113104.25938@rodan.acs.syr.edu> <1772@culhua.prg.ox.ac.uk>
Reply-To: greeny@top.cis.syr.edu (Jonathan Greenfield)
Organization: CIS Dept., Syracuse University
Lines: 45

In article <1772@culhua.prg.ox.ac.uk> geraint@prg.ox.ac.uk (Geraint Jones) writes:
>
>The implementation can only be `secure' in the sense that it implements the
>language as defined.

That's all that I said.  Perhaps I should not have implied more than that.
  
>In any non-trivial language with while loops, you
>will never get a mechanical guarantee from the compiler that the program
>terminates.  In the same way, in any dialect of occam with CHAN OF ANY,
>you will not get a mechanically checked guarantee of proper channel use.
>And serve you right.  Of course, you might want a compiler for particular
>applications to reject CHAN OF ANY declarations, but then it wouldn't be
>an occam2 compiler, would it?

Sure enough, you are correct.  That just says that "unsatisfactorily" matched
processes synchronizing via a CHAN OF ANY can be part of a *valid* occam
program.  (Analogously, as you point out, an infinite loop can be part of a
valid Pascal (for instance) program.)

Now, I'm really not familiar with the occam 2 definition of communication
over a CHAN OF ANY, but the fact that such programs are valid seems to lead
to a problem.  Namely, the parallel composition of two deterministic, valid
processes may yield one (overall) process when the composition is within a
single transputer, and may yield a completely different process (STOP, for
example) when the composition involves two transputers.  

Now I haven't checked, but I have been of the impression that the occam 
definition has intended to make PAR and PLACED PAR identical in composing 
two or more processes into a single (overall) process.  (That is, the only 
difference should be in the system's implementation of the composition.  
Abstractly, the composition is identical.)  If this is the case, then the
system would appear to be doing something to violate the definition of 
occam.

If, on the other hand, occam does prescribe such a differentiation, then
the system is fine, but (at least this feature of) occam sure is a mess.
I know I wouldn't want to be working on the semantics for such language
features (so tied to implementation details).

Any thoughts shedding further or better light on this question shall be
greatly appreciated.


Jonathan