News for hackers. Stuff that matters.
Re:New Paper: Theory of Programs by ble on Monday July 06, 2015 @03:27PM (#9841580)
Anyone find the definition of `functional` a little bit odd?

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?

Re:New Paper: Theory of Programs by Garlef on Monday July 06, 2015 @05:47PM (#9842392)
Agreed. Some definitions are really bad. I guess the cause is noble but it is executed very poorly. ( The definition of functional is also used nowhere in the document - Although it is mentioned. )

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.