In E-nets, tokens arrive/exit through the peripheral locations, P. These are net input/output terminals. (NN73,p.719)
Any example net, may act as a subnet (or, macro) with its environment, where that environment might be another net attached to the example net, at a(n input or output) peripheral location (NN73,p.721).
When the net acts as a subnet, the E-net primitives may manage the input/output process. In Fig.2 of NN73 (p.721), the X-transition (a1) at the entrance, and the Y-transition (a5) at the exit, are two examples for this.
There are five E-net primitives (p.719), although with macros, we may add many more. NN73 forwards macros to enhance representational convenience and clarity (p.721). Macros are used for new alternative patterns (of behaviors) at the entrance/exit of a subnet/transition.
Macros are for macro-hierarchies, too, as NN73 notes that, E-net representation is a hierarchy, even when the examples may show only a single level, or two (p.724). This page discusses the entrance/exit. Another page discusses the part of the plagiarism of copycat82, about the macro hierarchies.
Build the macro first, then render it any time, anywhere, again. With macros, new input/output patterns are available, both with the extended versions of the primitives (e.g: Jn, Xn), and all-new (e.g: Q-macro, An,m).
E-net is very versatile. Although the SARA authors refer to E-nets research, as an effort that influenced SARA, when they moved from their UCLA-graphs base, to build the SARA software system, the UCLA i/o control logic is kept, instead of the more versatile E-net primitives.
The SARA authors prefer a relatively limited strategy, but probably for a good reason, of their own. SARA keeps its past successes, inherited from UCLA-graphs work. The strong-reduction algorithm of UCLA graphs, compresses a net. This improves the performance of the reachability test. This occurs transparently, without human intervention. The limited-set of i/o logic elements, are the studied: and, inclusive-or, exclusive-or, and priority. The UCLA/SARA graphs represent these i/o control logic operators, with signs, between the input/output arcs to/from a control-node.
SARA supplements its (UCLA) i/o logic, to the similar of the versatile E-net macros, with the SARA SL (Structure Language) modules. The i/o control logic is the primitives-side, whereas the SARA SL modules are the macros.
Although SARA presents its methodology, with SARA SL modules, with a thorough software support, this is not verifiable as it is. Therefore, the software must transform it, first to expand those modules together, as a full net, and next to run the reduction algorithm, and after these, the verifier, in SARA CFA, verifies it.
It is absolutely trivial to imitate SARA i/o logic with the E-net macros. In fact, except the inclusive-OR macros, the others already exist as the E-net primitives, any way. To nest expressions with parantheses, formally, even without any shorthand-macro (although it is also trivial, any way), we may simply list the (paranthesized) subexpressions, as the locations for the E-net primitive that refers to them. The Xn-transition is a ready example, as it corresponds to the "exclusive-or" output macro of SARA. e.g: An Xn that lists three locations, as the alternative paths, which may, in turn be other such SARA-style macros. This is trivial, although not necessarily the preferred Macro E-net style. The E-net macros favor new abstractions. This is what provides their clarity. Nested-macros, to provide a single logic-gate may feel less than perfect, as it is spread around. That was obviously not the preference, when NN73 presented the macros (p.721), e.g: reflect on macros such as Fn (instead of "a and (b and c)"), and An,m.
copycat82, when it cuts-and-pastes SARA and VD78, into E-nets, it only abridges them. It does not suggest even a single advantage, but it is the vice versa. i.e: copycat82 looses in every way.
The E-net versatility is lost, when copycat82 adopts the limited set of SARA control logic, along with the limitation that the input-side does not manage with data. For example, this does not let a subnet/transition to adapt its response, after it has found a token, in an input-location/path, five times in a row, and it wants to let the less-visited path have the priority, the next time.
With SARA, only the output control-logic is data-dependent. Although the SARA interpretation-domain may state a preference about the "@output_arcs," there is no such preference about the input/entrance side. This is imitated, in copycat82. This means that copycat82 may not have a full Y-transition, but only imitate various states of it, or alternatively, randomize the path-selection (as with "++"), as another dataless input-procedure for the Y-transition.
It is not clear, whyever this is imitated by copycat82, which does not reduce, and most probably, it cannot do it, at all - with the quirkiness of the entrance/exit macro implementations, of copycat82.
For example, "inclusive-OR output" cannot be reduced with "inclusive-OR input," because, in fact, the "OR-in" is only a misnomer. It strictly requires that both paths are deposited tokens, before it resets to enable a next-turn through itself. i.e: "inclusive-OR" does not input multiple requests, if sent only from a single side. As such, it is not "OR" behavior, at all. It is strictness, to take turns. i.e: the input "inclusive-OR" would not reduce the output one. As such, they cannot be placed at the start-to-finish of a path, as so usual in forks-and-joins, in system-examples. Neither would the "++" fit, because it causes variable amount of tokens. Although it is trivial to prepare an OR-input macro that would fit, copycat82 cannot do it, itself as also with the other immense number and variety of faults it contains.
For another example, the "priority" input macro, non-deterministically loses priority, after the first pass through the higher-priority path. How would that "input logic" behave in a loop?
If that were all, we would refer to it only as "severely limited." But it does not stop there. After such an abridgment, copycat82 publishes examples that altogether ignores the necessities. The examples appear as if they code with SARA SL, with the SARA SL module sockets. That means, multiple, independent input and/or output paths in/out of a subnet. This needs expansion, as any macro does, before a verifier may make sense of it.
In fact, the case is so problematic that, the input-expressions of copycat82 would not suffice. (i.e: the "data-independent-control-transfer-specifications" cannot represent multiple entry points to a subnet, as it is only the SARA i/o control logic expression, which cannot represent the full SARA SL structure.
By itself, a shorthand, such as the SARA i/o logic may help only a little. The SARA extras, the GMB, and the SL are valuable supplements. The (implicit) false assumption of copycat82, about the "interchangeability" of SARA SL modules, with SARA control nodes, and its cut-and-paste as an "E-net alternative" is the topic of the page that discusses the plagiarism of copycat82, about the macro hierarchies.
i.e: copycat82 cannot possibly express its examples, with such a "separate/independent paths" in/out of a primitive. SARA also cannot. This is no problem for SARA, because SARA keeps the control-node primitives, and the SARA SL modules as separate kind of entities. With SARA, any input/output expressions must have coherence, only within a single socket, not all around the module that may contain many sockets.
The collapsed representation of copycat82, to make the imitated-SARA'ness fit the E-net structure, leads to gotchas, where SARA and Macro E-nets differ.
In other words, yet again, the plagiarism pushes copycat82, to be limited at the intersection of the source papers. It is limited, instead of improve anything beyond any of those prior art papers. Stuck with its plagiarism.
In summary, copycat82 is a subset of all of the priort art it attempts to cut-and-paste. Even the mere UCLA advantages do not exist with the copycat82. i.e: It does not have E-net Y-transition, it cannot match SARA SL, and furthermore, it has a lot of quirks with those macro implementations, although they were very trivial. Even a teenager was supposed to prepare workable macros, at such a trivial level. But copycat82 cannot.
The Petri net primitives, places vs. transitions, serve different needs. Places fork and join alternative-paths, whereas transitions fork and join synchronized paths (altogether).
To imitate E-nets, or SARA, it is trivial to introduce macro-transitions that contain places within them. This collapses everything to the macro-transitions, but it is a bit of waste of states - especially fiven that copycat82 does not (or, cannot) reduce, too.
VD78 and Pe77 do not waste any net element. They use the Petri net formalism, as it is. This is the difference, when copycat82 is any different, at all. Otherwise, to name a place as "XOR-output" or as "++-input" would not present any new idea, for a Petri net. When these appear as if, at a transition, that may appear as "different." But is it wanted? It is only a preference of the UCLA-graphs primitives, over the Petri nets.
As such, copycat82 is also similar to the SARA CFA strategy, when it paints the graphs with UCLA input/output operators, and next, attempts to verify as Petri nets. But the (false) assumption of separately-verifiable macros, suggests copycat82 imitates VD78, about the verifier strategy. It overall, represents imitative of E-nets, paints and gives examples imitative of SARA, and attempts to verify imitative of VD78. And when we compare with SARA CFA, copycat82 also lacks the extras of SARA CFA. e.g: macro-expansion (without which copycat82 is absurd to verify), and control-states-reduction.
The sort of wastefulness is possibly why the input macro "and" of copycat82 is implemented without a place before it, although the words used in its specification, which is similar to the other input-macros, would necessitate such a (wasted) place. The other macros need a place, whereas "and" requires only a transition. The figure on page 129 does not have any such extra place, to provide the uniformity, and to park the token when copycat82 "removes the token immediately after the macro/"component" starts execution.
The implementation of "++ input" is, emphatically, imitative of VD78 Fig.4, with a copycat82-ignorance about, subnets versus (instantaneous) transitions.
In copycat82("PhD"), it is the start of the section "3.2.3. Components." In copycat83(paper), it is the start of the section "Software Components (External View)."
Peripheral links with neighbors/environment.input/output
For a subnet, a designer may prefer single-entrance-single-exit. e.g: In NN73 (p.723), the example "Fig.5.(a) stack processor" starts with a Y-transition, ends with an X-transition. This is, in fact, how a Petri net "nonprimitive transition" is supposed to be. Although, copycat82 subscribes to that in words, next it deviates a lot, in its examples - committing to vagueness.
See: Start of the section "3.2.3. Components" of copycat82, the "PhD" text. It is the section "Software Components (External View)" of the copycat83, the associated paper.
A few trivial cut-and-pastes exist, as macros, and/or macro names, to stand at the entrance/exit. The faultiness/quirkiness (in addition to triviality), is staggering. The page although trivial, also quirky/faulty lists those input/output gate macros.
Optionally, to correspond to the states of X-transition, and Y-transition of E-nets, (e.g: no resolution-token, or priority-first, priority-second, priority-none/random), there may also be operator signs between arcs, as if that were SARA (UCLA graphs) input/output logic. Even totally needless, and problematic, is the inclusion of some redundant rectangles for data-items, within the same graph, next to the rectangle/transition, corresponding to the resolution locations, but without any standardized index/value, to manage the token-flow. In fact, at the analysis, data is not taken into account.