copycat82's jerkin to E-nets resolution procedures

I pinpoint the plagiarism of copycat82, as its attempt to camouflage E-nets out, with a jerkin. The E-nets features, and restrictions show through, though. The camouflage is with cut-and-pastes from a few other well-known papers that were published a few years before copycat82 was published, and was, surprisingly, granted a Ph.D. degree.

This page, specifically, discusses the case about the resolution procedures.

Psi (E-nets) ==> F_out (copycat82)

A resolution procedure "can be thought of as a mechanism for modeling the influence of the environment on the action of the E-net." (NN73,p.720)

In copycat82("PhD"), the relevant text is the later part of the section "3.2.3. Components" (pages 50-57). In copycat83(the associated paper), it is the later part of the section "Software Components (External View)" (pages 737-738). This fits, here, between P and R, because with each peripheral-resolution location, a resolution procedure is associated. (A one-to-one relationship.)

A resolution procedure of E-nets, corresponds to an "@output_arcs = ..." statement of SARA (where the variable "@output_arcs" corresponds to the E-net resolution-location, for each node/transition that makes a path-selection). In copycat82, there are no explicit locations, or variables for this. The resolution is only implicit, in a resolution-procedure, with a resulting loss of, both E-nets, and SARA flexibilities, and without any gain.

SARA does not necessarily decide at entrance, but lets that preference to be set anywhere within the interp.domain. SARA does not allow resolution-token-flow, though, from within the net. It always needs a programmed-statement, if not altogether non-deterministic, as with multi-arcs. The E-net interpreter would always consult the resolution at the start, when it is relevant, but it has its own flexibilities. An E-net resolution-token is depositable, as any token is, from within the net - visibly.

And when an E-net transition is making that resolution at the entrance, it is providing an opportunity of alternative-procedures to be run, too. i.e: SARA, and copycat82 always have a single body of code, for a node, but E-nets let alternatives. This latter is, rather, about whether the path-selection is executed at the end-of-the previous node, or at the entrance of the current. The strange thing about copycat82 is that, although it decides at the exit, the data-value it refers to, is that at the entrance.

An example path-preference

copycat82 duplicates the E-nets formal structure, with a make-up imitative of SARA. With SARA, you may write a path-preference code-fragment in a node's interpretation-domain as

count = count + 1

if count < 100 then
	@output_arcs = "go_on"
else
	@output_arcs = "stop"

In copycat82, this example would be a resolution-procedure (or, a "data-dependent-control-transfer-specification" as copycat82 calls it), written as:

if count < 100 then
	{go_on}
else
	{stop}

You may wonder where the counter-increment has gone, as compared to the SARA example. With E-nets, variables are modifiable only by the transition-procedures (or, "data transfer specification," as copycat82 calls it). i.e: It has to be presented separately.

With E-nets, a resolution is consulted at the start of the firing - whether it is set from within the net, or with a resolution-procedure. With copycat82, it is defined to be at the end, although the data-value it refers to, is the value at the start. A simple comparison with the SARA example would tell you that, if it modifies any data, before a decision, then the corresponding two procedures, in copycat82 examples, must duplicate the code. In fact, even this was not a new idea, and the prior art (Da80) stated it explicitly: Da80 (p.638) suggested that both procedures have the same logic, but the resolution-procedure selects the path, without modifying the variables (data), whereas transition-procedure may modify data. As such, Da80 runs two-passes, over the same code. As a result, copycat82, is all the same - except being vague.

At the intersection:
copycat82 as a subset of both E-nets, and SARA
(w.r.t. procedures, too)

Both SARA and E-nets have their advantages in R'ness, and copycat82 is a subset of both, at an intersection of both, and it cannot except for structures that fit both E-nets, and SARA. E-nets have multiple ways for setting the index-value, and the result is visually identifiable, at the resolution location. In copycat82, there is only the resolution-procedures for this purpose. This was not available in SARA, and it is not available, in copycat82.

In E-nets, a resolution must exist, at the start of transition-firing. e.g: For an X-transition, first the path is selected, and after that, the data is modifiable, in the transition procedure. SARA is more flexible about that. It merges resolution-, and transition-procedures together, and there is a statement, (@output_arcs="...") that may exist anywhere within that, combined, interpretation-domain. This is not available in copycat82, as it was not available in E-nets.

copycat82 does not discuss anything about the data-access semantics/sequence/timing. There is a single example (on page 67, which corresponds to the Fig.3.7.(e) on page 68), to infer these relationships. The resolution procedures, F_{out, i}, in copycat82, must refer to the data-values at the time of entrance, i.e: the values that existed before that transition modifies anything (with its transition procedure, G_i), although it is controlling the exit only. Are we to guess, that resolution-procedure is positioned after the transition-procedure?

copycat82 does not mention whatever would occur, if other transitions also exist, and modify the data, simultaneously. Then, even a Da80'ian (p.638) double-passes idea would not save copycat82. Da80 has no problems, because it is E-nets, any way, and the resolution is at the start. If we patch copycat82, by assuming that the F_{out, i} is computed at the start, although it controls only the exits, this is similar to the internal-sequence of an X-transition of E-nets. Therefore we have shown that this aspect of copycat82 is similar to E-nets, or a subset of E-nets, because copycat82 omits conflict-resolution at the entrance (the Y-transition of E-nets). This was not available in SARA, and it is not available in copycat82.

Even the names F_i, and G_i existed in Da80, with the same meanings, i.e: resolution-procedure, and transition-procedure, respectively - although copycat82 never cites Da80, anywhere.

As a result, because of being at the intersection of both E-nets and SARA, an attempt to present examples with copycat82, is always prone to gotchas. You may attempt to code something, because you thought it was available, but when you switch the presentation, from formal to visual, or vice versa, your example may not appear representable with copycat82, any more. It is an obvious seam, because, after all, copycat82 is only a cut-and-paste monster.

For example, you cannot have both a resolution-procedure, and a transition-procedure for a copycat82 transition, if you would like to see it visually, too. For SARA, this is no problem, because SARA unites both of the E-net procedures into a single code-fragment, the interpretation domain. It is SARA, next, with those nodes that have code-fragments in them. Not E-nets. i.e: copycat82 is applicable, only when an example is, trivially, representable by both E-nets, and SARA. You should, then, prefer E-nets, or SARA, to benefit from their extras, instead of being crippled at a gotchaful intersection.

...

The copycat82 writes the text of the resolution-procedure in the node (rectangle) - similar to SARA/UCLA nodes, again. But the SARA resemblence is rather fragile. The E-nets are drawn in SARA'ish looks. If you like SARA looks, more than E-nets, you may do that - and it is absolutely trivial. But, next, you cannot even infer where do the resolution- nd transition-procedures get written, separately, where there is only a single bubble/rectangle per node as the SARA and copycat82 draw it. i.e: There is a mismatch between the E-net formalism that distinguishes between the two, and the mildly-repainted (to look SARA'ish) figures, posting program-fragments (as SARA posts PL/I code).

Guess: Da80, in its text, lumps resproc and tranproc together. But in formal part, Da80 discusses them (F vs G) separately. That is probably where the copycat82 confuses the two-piece formal structure with SARA-single-piece nodes. But Da80 makes it clear that (p.638), there are two passes, that fits the E-nets architecture. A resolve-the-flow pass, and a data-modify pass, with (exactly, or essentially) the same procedures (p.639), for both passes.

F_out Macros
expensive, quirky, impossible

Things even make more sense, when you recognize that those macros could be of some worth, if the copycat82 subnets were E-net transitions. i.e: a single token/location is active, with a transition, at a time, while the others are waiting. In such a case, it appears, copycat82 has attempted to implement the three decision-structures of JSP (Jackson Structured Programming), as macros, but that is only absurd, if you remember that, the verifier that would verify all these, would be a Petri net verifier, not an E-net verifier. It appears, copycat82, while copying E-nets, has forgot that it is not an E-net verifier.

The wait-until-next-location-is-empty rule is central to E-nets, whereas it is irrelevant to Petri net verifiers. Furthermore, with E-nets, when a transition, for example, an X-transition, is active, even if the destination-location is empty. In this case, the preceding location forces the inbound token to wait. i.e: The wait-until-empty rule is E-nets. About this, copycat82 is rather vague, if not exactly suggesting a dump-away of any model, that has such a wait-blocked possibility. But this, not only dumps almost any net that contains any input macro "except" the ordinary Petri net transition (called "and-input"), it also makes it meaningless a few of the output macros.

(In SARA, this should correspond to the SARA CFA module, as SARA translates its UCLA graphs to Petri nets.)

F_out vs. T
An Unresolved Duality