Re: CHAN variants

["B.M. Cook" <barry@xxxxxxxxxxxxxx>]

Adrian, et al.,

I'm not sure what Tony Hoare means by: "We shall observe the convention that
channels are used for communication in only one direction and  between only
two processes."  [Communicating Sequential Processes, Prentice-Hall, Section
4.2]

Is this a complete requirement, or just a convenience for what follows (with
reference to PAR)?

If this is a requirement of channel usage between PAR processes, it is a
usage rule to be checked ... and a characteristic of PAR.  This would leave
us free to impose a different rule for channels under SYNC, that a channel
may have more than one destination (and might also have more than one
source, but maybe guarded to prevent contention).

> COMMON CHAN OF bits common:
> SYNC
>   common ! v
>   common ? x
>   common ? y

And with this new rule, the "COMMON" is not required.
[My hardware viewpoint says this is OK, a channel can certainly be monitored
from several places if we have synchronized the hardware.]

> Note that writing
> 
> COMMON CHAN OF ECL common:            might not be wrong if we had a
> SYNC                                  "wired-OR" ECL signal. Actually, I
>   common ! v1                         think that this should be illegal
>   common ! v2                         (aka bus contention if v1 <> v2).
>   common ? x                          And the ECL implicit OR gates should
>                                       be made explicit....

I'd prefer the explicit OR gates, it saves asking "what if there is
contention?", simply by making it impossible - a sensible design goal for
hardware.

> Although
> 
> COMMON CHAN OF blah c:                [2] CHAN OF blah c:
> SYNC                                  SYNC
>   c ! v                 is equiv to     c[0] ! v
>   c ? x                                 c[1] ! v
>   c ? y                                 c[0] ? x    
>                                         c[1] ? y
> 
> I don't think that the RAZOR means that we should use a cumbersome verbose
> notation for a simple idea. Of course, in software/hardware codesign,
> an "ocham" compiler would make this transformation when it was emitting
> "software" rather than "hardware".

I still think we can do away with "COMMON".


> PS. Any advance on COMMON ? Jeremy Martin suggested MULTI. Any more from the
>     rest of you occamists, and have you all been subverted into Javaists? 

I suggest <NUL>, see above.

		       Barry.
-- 

/----------------------------------------------------------------------------\
| Barry M Cook, BSc, PhD, CEng, MBCS         Department of Computer Science, |
| Chartered Information Systems Engineer.    Keele University,               |
|                                            Keele,                          |
| Phone: +44 1782 583411                     Staffordshire,                  |
| FAX:   +44 1782 713082                     ST5 5BG,                        |
| email: barry@xxxxxxxxxxxxxx                UK.                             |
\----------------------------------------------------------------------------/