Two-be, "OR" not to be!

The so-called "inclusive-OR" input-macro of copycat82, is not proper. The name "(inclusive) OR" would suggest, "either, or both." But the implementation is such that, it needs both entrances to receive tokens, to be able to restore itself. Otherwise, it will be blocked, in any later passes, through it.

The specified behavior is that it is supposed to be run only once whether p1 or p2 or both are enabled (holding tokens, that is). If p1 enabled the component, p2 cannot restart it. The second/matched token is only absorbed. That specification (p.46) does not suggest the blocked-unless-strictly-turn-taker behavior of the implemetation on p.129.

For example, if p1 is enabled, that macro-gate sends out a token. But next, that macro-gate needs a token also in p2 (to do nothing but to restore itself to its original state). In other words, if the circuit "enables" the operator several times by using the same place (e.g: p1), the tokens will only pile up there - until the other place does the do-nothing transitions to match each firing - unless the verifier dumps it away because it is not 1-bounded.

Is it Soviet (or, War-time) Petri nets, to ration with that "inclusive-or?" i.e: You cannot take a second bite, until the others eat as much. What "or" logic is that? One may still find some meaning to use it in an example, but that is not what copycat82 does. That Un-Credible Ph.D. lacks any proper example with it.

As a point to notice: In the "monitor" example (p.72) of copycat82, one of the absurd problems where "xor" is used, would not exist if that were "or." It is still very idiosyncratic, though.

It was trivial, any way.

For the readers, if interested, I could suggest two other implementations, for a real "inclusive-or" macro. e.g: To resemble/imitate SARA/UCLA graphs inclusive-or, as with SARA CFA. Even if copycat82 were any success to implement inclusive-or this way, that would still be no big feat to reward a Ph.D. title, any way, though:

1. With inhibitor arcs, and three transitions, each entrance may inhibit (a separate) one of the transitions. Thereby, when both have a token, only the transition that removes the tokens from both, would be able to fire. This is proper, and live, too. (Although copycat82 uses inhibitor-arcs, in other macros (xor and priority), where it commits yet other problematic consequences, it does not use that with inclusive-or.)
   
   
2. Alternatively, with E-nets, an X-tran may follow a Y-tran, to absorb the later token (send it out of the net) - if it arrives while the subnet is busy, but not if it arrives later.

Further Reading

The plagiarism of copycat82 encompasses its input-gate, and its output-gate, too.