Ready.

Q/A: Abstract, or Surreal? An Existential Problem.

The overall picture is that, except the false-claim of abstract-data-types (ADTs), anything and everything in copycat82 exactly corresponds to the E-nets formal structure - but with errors.


Myth: copycat82, as if introducing nets, with Guttag's Abstract Data Types

The case with an ADT is strange. If there is anything new, where is it discussed? If nothing new, why bother mention it?


With no restrictions, an ADT is only a label

Thinking about it ourselves, we may reflect that, for passive types that have no exceptions/restrictions, no separate feedback is necessary to the net-flow, (e.g: a "boolean" type). In this case, we may neglect the ADTs, and let E-nets abstractions, as they are built with the E-nets resolution and transition procedures, to go on to manage those variables, by themselves - without ever referring to them, at all, for example as "with an ADT of boolean."


Who resolves, between the conflicting resolvers?

But if those were active types, ever so trivially, then we need a higher level of resolution, to resolve between the decisions of a resolution procedure, and the decisons of any separately-deciding ADT(s). For example, even the rather trivial examples of divide-by-zero, or an array-out-of-bounds exception, if this is managed by an ADT, that is, if there are no "if-else" structures explicitly in the resolution/transition procedure, how does the resolution/transition procedure learn about an exception/restriction? Whose decision overrides (resproc/transproc versus ADT), and when? A token may get lost in some trans-proc, and reappear somewhere else, for example, if it would be similar to exception-handling in C. That is not what Guttag does, but that is possibly what would be, if an ADT gets inserted in the middle of a program-fragment, with its own separate program flow. What would copycat82 propose? It is mute.


changed what?

Trivially switching the computer-language used in those program-fragments, without doing anything new with them, is not any improvement, beyond the prior art ((Macro) E-nets, SARA, etc.) It is the prototypical plagiarizer's case: Translating work, between different computer-languages, and/or changing a few names.

Even any example ADT-studies are non-existent in copycat82, let alone any new idea in the field of computer-languages. The ADT-advertisement stands there, as such, only as an attention-diverter - maybe camouflaging the plagiarism, until you read it seriously.


Restricting, and Missing

The named but omitted inclusion of Guttag's version of abstract data types, then, is only an absurd feature. It is only overspecifying, in this context. Whatever the data-representation may be, they are only somewhere behind some predicates, or "data-transfer specifications", which are heard of, but not seen in copycat82. There are no discussions in copycat82, about how the very separate formalisms would be inter-related (Petri nets, and algebraic data specification) - "except" naive displays of rectangle-partitioning, even which also have their shares of faults and/or omissions, as we will discuss.

Guttag, in that tutorial paper (on page 23), suggests that the type-system he studies, is preferrable for "a type abstraction that is not readily represented or modeled by a well-known type." As such, it is absurd, to find that copycat82 (over)specifies the particular type system, but next, does not present any type studies, whatsoever - let alone integrating with Petri nets.

In fact, it was the NN73 that included new abstractions such as a queue/stack with options to re-order (the Q-macro location), a resource-handler (RH-macro), and a few (extended) operators, Jn, Yn, etc. This was well-beyond the "Turing tar-pit" that Guttag refers to, I think. In fact, NN73, when presenting macros, for E-nets (on page 721), already state that, without macros, "if one is limited to these primitives, the resulting net ... complexity obscures function ... defeats one of the principal purposes of the development of E-nets." In other words, it is not a random co-incidence that, the Macro E-nets improve meaningfulness. That was the intention, from the start - with (xi,Psi) coupling, etc., and next, with macros. It is the point, beyond which, copycat82 cannot improve. In fact, copycat82 is not even there, when we observe its self-contradictions surface.


the false excuse

The false-suggestion, "why" specifically, the algebraic variety was proposed, is stated as its being "closer to the set theoretic nature of copycat82's design representation." (page 41, in copycat82). But this is not how Guttag differentiates its system, as contrasted to Hoare's. And it is not clear what copycat82 means, if anything. It is only a rush to introduce "some feature, whatsoever" it appears, and the feature was to be the naming of guttag's type-system, as an attention-diverting, false advertisement.

To oppose such an overspecification, by contra-position, I notice that, the Hoare approach could fit Petri nets, very well, too, (possibly even more fit) - if anybody would really take his/her time to study it. Here is an initial pointer: the Hoare-triplet very well fits the Petri net transition/subnet, with its in/out places. i.e:the three sets, in both cases, correspond to each other.

A bit more advanced pointers:

In other words, only mentioning Guttag's name, and his tutorial, is not any improvement, by itself. It could be a research question, if at least, we could tell what it was expected to improve, beyond the existing net studies. Not to mention that, a question has to be answered, too, before obtaining a Ph.D. degree.


copycat82 vs. Petri nets
anything could occur, anytime, anywhere?

The ADTs are not the only. We find that copycat82 is totally-chaotic with net-nodes, too. In copycat82, a node/"component" does not have any such requirement that a fixed number of tokens should enter/exit. After the first time it is enabled, that node may release any number of tokens, any time, forever. In fact, the ADTs only make this even more chaotic, because, with ADTs, possibly, a node does not even need to be enabled first, before releasing any tokens. There are no examples for this, in copycat82, but when we imagine the proposed multiple-step-token-release-when-enabled (on pages 53-54, the "superscript"), with the ADTs exception-management, anything may occur, anytime.

How would that be verifiable, especially when all the data (with their "data-types") are neglected for the reachability-test of the Petri nets? The model lets arbitrary behavior, but the Petri net verifier expects a fit to special restrictions, in abstraction.

VD78 was already a prior-art paper with multiple-levels of analysis. The first-level of VD78 is the Petri net reachability test, neglecting the data. But to make it workable, VD78 pay special attention to ensure the subnets to be well-formed (such that, it is assumable as a primitive transition, for a Peri net verifier's purposes). But to arrive the VD78, any violations that do not follow the VD78 restrictions must be expanded as macros - as NN73 do with their macros for E-nets, and as SARA people must do so with SARA SL modules, before verifying with SARA CFA, as a Petri net.

Now, the problem is a double-edged sword: It cuts either way. If those ADTs are confined to individual subnets/nodes, expanding them as a macro could be easier, but that would not be anything different than what we already had. Or otherwise, if those ADTs have their separate interconnection logic, behind the scenes, as a duality, with its own intricacies, that would need a very involved macro-processor to transform/expand those macros to make such a net correctly verifiable, as a Petri net. Please, keep in mind that, no algorithm, not even any examples exist in copycat82, for such ADT-to-net transformations.

As a prior art, see NN73 examples with queues (p.722), and alternatives-in-representation (p.724). Da80 discusses these, but an X-transition always fires as a single-token-in-single-token-out. Da80 does not suggest a separate ADT, to go with E-nets, either. In fact, I would interpret Da80's inclusion of a discussion, in section "IV.F Programming Languages" about hybrid models, right after the section "IV.E" where the E-nets are mapped to a two-level FSA, as a suggestion that E-net, in itself, is a hybrid that is sufficiently formal.

Although copycat82 never cites Da80, at all, some very similar patterns do suggest even a plagiarism in copycat82, and here, in the case of ADTs, the reason why copycat82 introduces yet another hybrid, might be a misinterpretation that "something yet further may need to go with E-nets." But when we look carefully, there is no further substance about it, in copycat82. That is, in fact, where, copycat82, at first appears a bit different, is only its false (unsubstantiated) advertisement.




The content, hereafter, is mostly the same - with different words.

I may later edit. Readable, though.






Absurdity in the declared-but-missing

The E-nets let the programmers isolate data-dependencies, with the resolution and transition procedures. VD78, have predicates, and operators, corresponding to these. The standardized-interface, lets programmers/designers free at design and implementation decisions. And either predicates, or other structures used, presumably, let for other verification strategies also be used, with assertions, self/process-reflecting programming, etc.

Abstract or Surreal? Both VD78 and NN73 employ predicates to deal with data-dependencies - which is some implicit form of abstract data-typing (the combination of data-items with the acting-on predicates, with some standardized interface for the result). After this, copycat82 imitates suggesting, instead, using the explicit, algebraic approach of the tutorial paper by MIT's Guttag (1980). O.K. Do it and let's see. But the problem is that the content is missing. There is only a summary of the (Guttag's) tutorial paper, in a page or two. Neither discussing the specific improvements that would be brought by that particular choice, nor how to apply it in this context along with Petri nets, etc. Only some rectangles with type names in them, in a few sample figures.

In other words, there are not any worked-out examples that apply the suggested (algebraic) approach in this context. Not the least of a full method for others to be able to do it, with detailed care for the steps and the consequences.

The copycat82, explicitly names a particular method to be used, for data-relevance. That brings to mind, a question: Why name a specific data-abstraction method? How does that improve the particular model? The copycat82 is silent about that, and there is only a summary, of a tutorial paper by an MIT professor, Guttag (1980), without an integration into the Petri net token flow. It appears then, before asking the "why?" question, we need to ask the "where?" question. Where is the formal integration, and/or examples? Does only a naming of some valuable work, as "to be included" suffice?

The proposed ADTs are missing, except a single page or two of summary from that not-Petri net paper, and that tells nothing. The whole thing is again isolated behind a procedure or predicate (as in the NN73, or VD78 case, respectively). Then, why bother even name such a specific abstraction-style, if not to integrate it in some formal fashion and/or to use it in the examples (or, expectably, both)? It is just a page-filler proposal, which is not substantiated. The strangeness, then, is also about the "single-graph"ness. If a whole world of a different abstract-data-types formalism would be behind such a network of procedures (very exactly as in the case of E-nets, or as a collection of predicates, somewhere, each being fired by transitions as in the case of VD78), at each firing of a transition, then why call it a "single graph"? That is not true (Again; for this other reason). A sentence, yet another false claim, in copycat82 suggest that ADTs will be gradually the code in the boxes itself, but we find no examples of it, in copycat82. In fact, that is about the correspondence between those ADTs and Pascal, and has nothing to do with copycat82. It is, again, only talking of something it has not invented, not even implemented, itself. The inherent correspondence I cite, may only be an attention-diverter when you ask "Where is it?" Such an attention-diverter, then must be assuming that no second question will follow like: "If it is not part of your work, why do you include it among your claims about your work?"

See, the discussion at the end of the Danthine's paper, as well as many others, discussing the difficulties of integrating different formalisms. The copycat82 appears to believe, only placing the Pascal program fragments in the rectangles, passes also as "using abstract data types" when there is an assignment statement, or a "msg(snd,j)", etc. That is nothing serious. How has the jury has been convinced to approve only a summary of a tutorial paper, as a contribution - and not as a negative point, as it restricts/suggests the programmers to commit to a particular method, without any particular relevance. That is overspecification. And the provided is only an illusion.

And that is very especially strange, because, unlike those other researchers, although copycat82 advertises (imitates to attempt), to use a specific abstract-data-typing method, abstract-data-types as described in a tutorial paper by Guttag (1980) - referred to, only as a summary in a page or two.

But that paper is not in a Petri net context, and it is not Pascal either. It is a third, different formalism, a whole different style of abstraction paradigm, by itself. When such an explicit specification of the expected data-typing method is given, I expect to find WHY it is so explicitly chosen in this Petri nets and distributed systems context. The copycat82 not only states no justifications whatsoever, but also declines to provide any studied examples of it, so that we could observe it from the examples, why and how it is to be used.

At the end, copycat82 does not provide any formal treatment/integration, and no examples of using it that would suggest why it cared to mention the name, at all. And at the end, it is only a gross, attention-diverting claim, and copycat82 delivers nothing further than what NN73, and/or VD78 had already implemented.

It is even less. Except a single example (and a sample), it does not even write how the control and data may relate, at all. We may infer from that single example that, copycat82 adopts the E-nets formalism, but attempts to paint that imitative of SARA. As a result, if something does not fit either one of these, that cannot be represented with copycat82, the cut-and-paste-monster. (We discuss this on other pages.)

At the end, if something had been "introduced," I guess, it would something like the resolution predicate of NN73, or the operators of VD78. i.e., resolving indeterminacy by referring to the data-specifics. And then, we would also carry this section to a page that discusses the plagiarism aspects in the paper. Because, if wrapping the whole thing in a predicate, and only giving a summary of a tutorial paper of MIT's Guttag (1980), in a page or two, what are you claiming to be introducing? Both components were totally implemented already. Not to mention the demands of algebraic specification. Unlike NN73, and VD78, who have taken the practical approach of directly resolving with predicates, if you go on and also explicitly specify what will be behind those predicates, there may be some discussion needed to tell how you will manage the synchronizing two altogether different specification approaches. We can only guess by reflecting on how we convert Pascal programs to Petri nets, and vice versa. i.e: If a stack pops, you may make it a Petri net transition, but then what is the sense of specifically naming and summarizing a tutorial? The copycat82 is mute. It actually, then, only falls in the category of a page-filler that only exists to get/divert attention.




Any Questions?: . . (Request Content . . . . . Correct Errors . . . . . Submit Case Study . . . . . Report Content Similarity.)

LastUpdated: June 2, 2004
Page-version: 0
Written by: Ahmed Ferzen/Ferzan R Midyat-Zilan (or, Earth)
Copyright (c) [1994,] 2003, 2004 Ferzan Midyat. All rights reserved.