Another oddity: "Object oriented" programs are defined as functions {0,...,n} -> O where O is "a set of objects". Yet: A program is defined to be an endo-relation S<->S. Accordingly, we have O = {0,...,n}.
I don't see how this definition gives any insight on the nature of object oriented programming.
Now for the strangest thing: The definitions of "object oriented" and "procedural" involve differentiating between possible condidates for S. Yet the only property a set without any context really has is its cardinality.
So we can rephrase the definitions of "object oriented" as follows:
An "object oriented" program is a set S together with a total function S -> S with S finite. ([total function] AND [S finite])
Negating, we arrive at the definition of "procedural program":
A "procedural" program is either a relation S <-> S that is not a total function (no restrictions on the cardinality of S) OR any relation S<->S but S must be infinite. ([not a total function] OR [not S finite])
I don't see how this definition captures the notions of object oriented programming and procedural programming in any meaningful way.
But maybe the author will appear here and to clarify his ideas.
Is there a reason why a "no-op" or identity function should be considered imperative? Or why a program must be imperative if at least one post-execution state is also a valid pre-execution state?