JRA@vax1.esprit.southampton.ac.uk (08/10/89)
The Case for Anarchic Protocol ------------------------------ In a recent posting, G.J.A.Paul writes >Treat CHAN OF ANY as a bag on the side, there to allow easier >conversion of occam 1. In those days, all you had was a CHAN, and you >sent an integer tag to indicate what was coming next. Now we have >tagged protocols to take care of that sort of thing for us, and check >for silly errors too, we don't need to resort to this low level. I want to refute the implication that anarchic protocal has no place in properly written Occam code. Suppose an EXE is talking to a processor network, requesting various actions including regularly sending it a big data array. The obvious way of dealing with this is to use a variant protocol eg. PROTOCOL X CASE send.array; INT::[]INT do.something.else; INT Unfortunately, this means that you have to have a massive byte array at the input end of the channel, even if the process is just a buffer process that hands the array on to the process that really wants it. You may not have room for this buffer, in which case the next step is to break up the data into chunks eg. from.exe ? CASE send.array; p SEQ i = 0 FOR p/(SIZE small.chunk) SEQ from.exe ? small.chunk ... send it on do.something.else ... do whatever Alas, variant protocol won't let you split up an input line. Of course, you could define a dummy tag to head each block of bytes, but that goes against the spirit of the problem since you're paying in terms of performance to work round this shortcoming. This is the point where the "real" programmer, who cares about performance (as opposed to the "nice" programmer who cares about readability and program verification) turns to anarchic protocol and declares his own tags. This is not the only case where the PROTOCOL scheme of things fails. Another example is a stream of INTs where a particular escape INT signifies that the next item will be a string. The Occam definition could be altered to try to deal with these situations. Various possiblities are * allowing tag-free formats in variant protocols * a notation for an input statement which is to be continued * a hierarchical variant protocol where tags are allowed to specify a new sub-protocol However, until Occam has something like this, anarchic protocol needs to remain to allow the programmer to implement his or her own scheme when the PROTOCOL statement can't cope. James Allwright Department of Electronics and Computer Science, University of Southampton, U.K. E-mail: JRA@uk.ac.soton.esp.v1 or JRA@uk.ac.soton.ecs