🚀 go-pugleaf

In article <LLW.91May17095750@corwin.eng.yale.edu> llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb) writes (about CHAN OF ANY):
>->  
>->    The behavior of software and hardware channel communication in
>->  in the Inmos OCCAM2 compiler is not identical.
>->  ...
>->    Curiously, you'll find that your code sample will run fine in a
>->  configuration where the channel "to.p2" is a hard link, but not when
>->  it is a soft link. Try it.  The implementation of channel
>->  communication in OCCAM2 behaves differently on hard and soft channels.
>->  ...
>->  The moral of the story: If you use OCCAM2, use explicit protocols -
>->  even though they are cumbersome and restrictive.  It is hard to track
>->  down bugs without them.
>->  
>->  Note that ihe implementation of channel communication in the newly
>->  released INMOS ANSI C compiler does *not* suffer from this curious
>->  design flaw.

I'm not sure what you think is the design flaw: the programs in question
are not guaranteed to work (by the occam2 Reference Manual).  The only
`unexpected' behaviour is that Inmos' occam2 compiler happens to produce
code which makes this invalid non-program do what its author expected in case
the communication is on hard channels.  It is _very_ hard to guarantee that
all incorrect programs do something unexpected; the usual contract with a
language implementor is that all correct programs should only do the
expected.

The moral extracted from the story is fine, though.  Think of CHAN OF ANY
as one of those horrible messes that you end up having to use when the
other end of the channel is attached to something other than an occam process
whose behaviour you are able to determine.
									g