SNAP Issues: Incomplete Object Paradigm and Premature Typing

Hello colleagues!

In the previous article, we talked about the problem of the UNSN in general, in this article I would like to develop this topic and to show more specifically the problems of the UNSN.

Main ideas : SSSNs have two key problems: defective object paradigm and premature typing. A defective object paradigm does not define the concept of an untyped object composition (composition is the most important element of any paradigm). Premature typing limits the semantics of abstract concepts (semantic abstractions).

Defective object paradigm

The object paradigm does not explicitly define the underlying mechanisms. Any paradigm should define:

1. Primitive abstraction - defines the style of thinking of the paradigm and is the basic element of modeling.
2. Composition of primitives - allows you to describe (model) systems of arbitrary complexity. The composition itself must also be a primitive.
3. An aggregative relationship is an abstract mechanism that links primitives in a composition. Exactly the same mechanism manifests a primitive and in external interaction.
4. Global state - where (but not how!) The abstract (observable) state of the system will be localized. This property is not a paradigm, but a consequence of the computing architecture. The result of the execution of any model can be detected only by a state change in the most general sense.

In principle, the paradigm is defined in an untyped form . To use a paradigm (not to be confused with the use of PLs based on this paradigm), typing is not needed. The paradigm should only determine how and on what mechanisms the model is built (that is, one or several compositions).

More importantly, the composition, and not the primitive, is a "brick" in the simulation because of the complexity of the simulated systems. Compositions are pure semantic abstractions , without tying types or any other "resources". Semantic abstraction is a concept defined only by its name, and the name in any form, word or phrase.

For example, the functional paradigm fully satisfies these properties (the same can be shown for the procedural / imperative paradigm):

1. Primitive abstraction: function - display of some input to some output.
2. Functional composition: a chain of functions (mappings).
3. Aggregation relation: the output of one function is fed to the input of another. Those. it is a connection in composition, and a function call as such.
4. Global state: function arguments.

In OOP and the current definitions of the object paradigm, object composition is implied at best, at worst it does not exist. The so-called OOP postulates (abstraction / encapsulation / inheritance / polymorphism) are an abstract set of concepts, the latter two generally refer to typing and have nothing to do with the object paradigm. Everything is an object. Objects interact with each other. - here the object composition is at least implied, and somehow it can be logically derived.

Of course, it is technically possible to see the compositions in one form or another in an OSNP, but the object composition should be the basic and basic mechanism of an NPNN, rather than an optional and secondary mechanism .

What should the object paradigm look like (by analogy with the functional one):

1. Primitive abstraction: an object is an agent that supports some interaction protocol. The protocol implies the rules and semantics of interaction for both parties.
2. Object Composition: A graph of objects that support each other protocols. The graph itself is an object with its own protocol.
3. Aggregation relation: support for the object protocol (i.e., understanding and following the protocol). The ability to support each other protocol links objects into a composition, as well as external interaction with a specific object is possible only if its protocol is supported.
4. Global state: the internal state of the object.

A distinctive feature of the object paradigm is that the object, unlike the function and procedure, is not a purely transforming (ie, state-changing) primitive . Since the global state is distributed over objects (in SSNP this is encapsulation), the object protocol becomes a way to change state. This should be reflected at the level of the object paradigm.

For this, the object paradigm can use any paradigm with a transforming primitive, the actual functional and / or procedural paradigm for object protocols. Both paradigms are used in the same abstract untyped form. If the protocol of an object is based on a functional paradigm, we get a non-mutable object, and if on a procedural one, then it is mutable.

Premature typing

Typification (type system) is ultimately necessary for a single purpose: formal verification of the correctness of programs. The rules are set through the grammar of the PL, the translator based on the grammar performs the actual verification.

The prematureness of typing lies in the fact that SSNPs (class-oriented) place a strong emphasis on the use of types, on the interpretation of classes as types. The first thing that catches the eye (and both in practice when using NPNT and in textbooks / books when describing an NPNT) is the system of NPNT types, although in theory there should be an object paradigm with its composition and semantic abstractions. Reference types and value types, polymorphism of subtypes, inheritance, Liskov substitution principle (LSP), method overloading, generics, abstract data types, functional type and FVP as elements of functional programming, type inference, type conversion, abstract classes and interfaces - All these concepts are a consequence of typing.

On the one hand, typification is inevitable, since Only correct programs can be executed. But on the other hand, the emergence of typing imposes restrictions on the semantics of abstractions. The idea is to postpone the appearance of typing as much later as possible. In other words, a formal verification of correctness is carried out only after the object composition has been determined . Ideally, the typing should be connected, its place somewhere before the compilation stage, and already at the compilation stage the verification itself is performed.

If you look at typing more broadly, then premature typing in the SNAP is also manifested in the fixed interpretation of the abstract mechanisms of the object paradigm in the form of specific types of implementation . A case in point is an object protocol (it is a contract) that is rigidly implemented as methods with fixed structure and behavior (parameters, return value) as one of the possible types of object protocol implementations. The reason for adding modifiers of the async / wait methods in C # seems to have become clear that the rigid (synchronous) connection between the method call and the return value does not correspond to practical tasks. In fact, this is the correction of the consequences of premature typing. Again, ideally, a specific type of protocol implementation should be plug-in, with a specific implementation of any mechanism.

The idea of ​​connected typing seems to me in the form of several stages (this is not some kind of waterfall software development process, all stages occur while writing code without leaving the IDE).

An object model is described (one / several untyped object compositions), which contains only semantic abstractions. Objects, their protocols, composition of objects - everything is informally described in the form of semantic abstractions. At this stage, the meaning of the object model follows from the concepts themselves.

Then attribution occurs , i.e. definition (binding) of untyped attributes for semantic abstractions . As a result, attributed semantic abstractions are obtained. Attributes are not data fields, properties, etc. from the PLO / SNAP, the attributes define the semantic structure of the concept. At the stage of attribution, there is no concept of state at all.

The next stage is an abstract (untyped) implementation of object protocols (traditionally, the implementation of methods). For object protocols, the implementation paradigm with transforming primitives is chosen (functional and / or procedural). At this stage, attributes are already available, but they (like abstract functions and / or procedures) are still semantic abstractions. The use of transforming paradigms at this stage implies an abstract state of objects (since there is something to transform), and the structure of this state derives precisely from the attributes of objects.

Next comes a specific (typed) implementation - this is where the binding of types to objects and their attributes, as well as the parameters / arguments in the object protocols takes place. Abstract procedures / functions of the abstract implementation of object protocols are concretized into traditional constructions such as class methods.

Separately, I note that type binding occurs through the injection of expressions, and not an indication of the type name. In other words, the type is derived from the type of the expression, which guarantees explicit initialization.

After the concrete implementation stage, all concepts are typed, and formal verification can be carried out (as part of the broadcast).

Conclusion

The problems identified, in my opinion, are the reason why JSNF is fundamentally contradictory. It is not surprising that the SOBNP and the PLO in their current form will always be the object of criticism.

There is also a third problem, but it concerns not only SSNP, but also other languages: this is a syntax based on text grammar. Currently, the support for text grammars in the IDE is so developed that the question arises: why do we need a textual representation of the code? IDEs are manipulated by whole structural blocks such as methods or expressions that the text as such degenerates. Compare versions in version control systems as text? But this is only a question of the implementation of support in the IDE.

Text-based grammar syntax limits meta-capabilities for the same reason that the meta-level requires additional support from the IDE, and there is little point in specifying them as text. Those. Meta-features are implemented only at the IDE level. Essentially, an IDE is a grammar.

Therefore, a global idea is to develop an object-oriented language (ie, IDE) based on a coherent object paradigm, without textual grammar and with developed meta-capabilities for transforming object compositions into readable code.