[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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
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
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
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?
Dr A E Lawrence