... I think it would be much more natural to implement bidirectional
communication.As a first approximation, I would expect:
class SwapChannel
(object) swap(object)However, when implementing an Alt, people sometimes differentiate between
the input and the output side. In order to be able to implement the Alt
efficiently, one needs to distinguish the INITATOR side from the OBSERVER
side. The initiator-process cannot perform an Alt; the observer-process
can.The result would be:
class SwapChannel
(object) initiate(object)
(object) observe(object)Note: the "swap" looks much more natural like a method call.
I think this mail is an important step toward the union
of OO and CSP.Note: Claim: the "?" and "!" on top of core CSP are pretty much nonsense.
What you have suggested makes apparent sense. I'd like to add a
couple of things:
1) Although superficially similar, the occam3 call-channel (RPC-like mechanism) is different. This difference is important and is to do with server behaviour. In a call channel, the server end is able to do some computing before replying. During this time, the client has to wait. However, from the client's perspective, there is no difference between this and being an initiator on a bidirectional channel. In the special case where the server does no work, does this make a call channel the same as a bidirectional channel?
In occam: a call channel is asymmetric. A call channel is declared,
e.g.
CALL cosine (RESULT REAL32
result, VAL REAL32 x) :
and in the client it is called e.g.
cosine (cos.pi, 3.14159(REAL32))
whereas in the server there will be a part of a procedure body e.g.
ACCEPT cosine (RESULT
REAL32 result, VAL REAL32 x)
SEQ
calls := calls + 1
result := COS (x)
ACCEPT behaves (initially) like channel input and may therefore be an
ALT guard if required. However, the scope of VAL REAL32 x is limited to
the nested body of the ACCEPT, so the call channel is not behaving
like a bidirectional channel. To illustrate this, consider
CALL swap (INT back, VAL
INT forward) :
in the client
INT x:
SEQ
...
some work
swap (x, 10)
...
some more work, involving x
in the server
INT y, z:
... stuff which
initialises y
ACCEPT swap (INT back,
VAL INT forward)
z, back :=
forward, y
The key issue here is that the extra data copy (red text if you're reading this in rich text) is required in occam3, whereas Marcel implied that it would not be required. Of course, occam does not have references either (only data objects) so would have involved some copying anyway. The issue is that there would appear to be two copy operations on each variable, not one.
2) the distinction between initiator and observer *only* has meaning with regard to alternation behaviour. Aside from that, both ends of Marcel's bidirectional channel are behaving the same and therefore the distinction between them could lead to confusion. The distinction is necessary but unwanted; I don't see how to resolve this!
3) Tom Locke's work investigating a new language with strict aliasing control (presented in the Fringe session at CPA2000) is exciting because it suggests there may be a way forward to unify OO and CSP by drawing on long-established data-flow thinking. Without control of aliasing, the unification of OO and CSP is very difficult. Marcel's bidirectional exchange will fit the data-flow model just as well as a unidirectional flow, provided it isn't expressed in a (functional?) language that restricts flows to be unidirectional.
4) CSP can benefit from this bidirectional idea. At CPA2000, Adrian Lawrence showed how CSP can describe continuous events. He illustrated this using an LC tank circuit. Clearly, in such a circuit, the current flows are bidirectional. Now you might argue that they are sort of 'half-duplex' in that case, but I think that generally CSP would be able to describe synchronisation events between processes where information flows in both directions at the moment of the event. But now that CSP events can have duration (using Lawrence's continuous modification), the generalisation is complete.
5) the bidirectional channel implementation on links (and other such inter-processor network) will be interesting!
6) occam needs a new operator, which must be ternary. :-P
Regards,
Rick
begin:vcard n:Beton;Richard tel;pager:ICQ: 56840977 tel;cell:MSN/Hotmail: richardbeton@xxxxxxxxxxx tel;fax:01794 833434 tel;work:01794 833458 x-mozilla-html:TRUE url:http://www.beton.freeserve.co.uk/ org:Roke Manor Research Limited;Internet Technology & Networks adr:;;Roke Manor: http://www.roke.co.uk/;;;SO51 0ZN;UK version:2.1 email;internet:richard.beton@xxxxxxxxxx title:Internet Consultant note;quoted-printable:The information contained in this e-mail is confidential and must =0D=0Anot be passed to any third party without permission. This =0D=0Acommunication is for information only and shall not create =0D=0Aor change any contractual relationship. =0D=0A fn:Rick Beton end:vcard