Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!mcsun!ukc!yorkohm!pete
From: pete@ohm.york.ac.uk (-Pete French.)
Newsgroups: comp.sys.transputer
Subject: Re: Anarchic protocol ANY (occam2)
Message-ID: <1991May23.100506.5466@ohm.york.ac.uk>
Date: 23 May 91 10:05:06 GMT
References: <1991May22.112448.22321@rodan.acs.syr.edu>
Organization: Electronics Department, University of York, UK
Lines: 52

in article <1991May22.112448.22321@rodan.acs.syr.edu>, greeny@wotan.top.cis.syr.edu (Jonathan Greenfield) says:
> 
> 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.

Yes the two are completely identical - but what you are attempting to do is
to place a program whos behaviour is _UNDEFINED_ usig the two sorts of PAR.
You end up with 2 programs both of whos behaviour is undefined - hence they
may behave differently for the 2 different PARs. It was really a bit of
a red herring for someone to mention that the program would work correctly
if the channel was a link - this is purely an accident of implementation.

CHAN OF ANY is supposed to be used where a channel will be used by moer than
one protocol - but not at the same time. The processes should still
input and output the same types of value. If they dont then the behaviour
cannot be predicted.


To continue this a bit further - I have often come across people trying to
use ANY protocols to make such things as universal buffers by feeding in
various protocols at one end and then reading out as BYTEs at the other.
Perhaps a usefull extension to occam would be something along the lines
of

CHAN OF ANYBYTE

which would work like a CHAN OF ANY but would guarantee that the data would
be sent as single consecutive bytes (this would be very innefficient though)
this would enable general purpose buffers to be written... so you could have
a library process called buffer.4k that could be used between and two channels
of the same type to insert a 4kbyte buffer.

Well written occam programs dont need this of course :-)

-bat.
-- 
-Pete French. (the -bat. )         /  "Two wrongs don't make a right,
Adaptive Systems Engineering      /    - but three lefts do !"

"Look here, a Brit who has obviously been driving in California!"