[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: occam-com@xxxxxxxxx*Subject*: Merging revisited*From*: A E Lawrence <adrian.lawrence@xxxxxxxxxxxxx>*Date*: Mon, 30 Oct 2000 12:59:28 +0000*Organization*: Not much

Since merging has been mentioned a few times recently, I should mention that I have revised the semantics. In particular, the original version had e & e = e In the revised version, e & e represents a pair of events. You will notice that I am using & rather than <> as the ascii version, Both overload occam operators, but I think & is probably more intuitive. I did wonder about && which also has the advantage of annoying C programmers :-) The new semantics regards events as bags (aka multisets). So the (universal) alphabet has the form \Sigma = \bag E where E is some set of "primitive" events. And singleton bags are in effect atomic events. Merging is really bag union, so e & e is just the bag [| e,e|]. I have written this up in a short paper, but have yet to add examples and applications, so it is unpublished. CPA 2001 if that is not too long to wait. I think that I have said enough here for you to work out the semantics, but if anyone intends to use or implement merging then we might need to talk. Of course, there may be problems that I have not spotted. Allowing bags within bags was something that I considered. That is more expressive and less abstract, and to be avoided on those grounds alone unless we really need to distinguish (a & b) & c from a & (b & c). AFAICS we don't need to do that, and in the current semantics both are the same as a & b & c , a compound event containing 3 atomic events. This of course smuggles true concurrency into discrete CSP, while retaining the usual arbitrary order in a PAR: we really can have our cake and eat it. The standard semantics is preserved even for merged events. But the new constructors like SYNC have their semantics defined in terms of merging and provide true concurrency (if that is how we choose to interpret them), particularly for compositional hardware compilation of mixed synchronous and asynchronous circuits. But all that is discussed in the original HCSP paper. Anyone see any problems? Adrian -- Dr A E Lawrence

- Prev by Date:
**RE: FW: A "CJT" in python** - Next by Date:
**Micro$lime at work?** - Previous by thread:
**A "CJT" in python** - Next by thread:
**Micro$lime at work?** - Index(es):