Routines are an abstraction for a sequence of statements in imperative approach.
Routines are a fundamental feature in object modeling part of Paml. Actually, messages of objects/subjects are routines, so any terms applied to routines are completely relevant to messages.
A routine is a sequence of statements. A routine is actually a statement too, so such recursive definition results that routines can be nested. Any one statement or several consequent statements can be defined as a routine.
In Paml, routines apply Template Method design pattern in generalized manner. A routine is actually a template method in this sense, because transformations can assign to the routine pre- and/or post- behaviors. In wider sense, in imperative approach, for any operation pre- and/or post- operations can be injected, since an imperative program is an ordered set of operations.
Routines are the most important area where transformations can be applied and this mechanism is based on aspects/advices from AOP. But in Paml, routines are more abstract and their role is much important. A sequence of statements can be marked as a routine, and after that the routine can be adjusted by transformations with new behavior via advices.
A routine can have a name. A message is a kind of routine that has a name by definition. Besides name, routines can have tags, which are like alternative names. Speaking in advance, tags will also be applied to other language elements such as objects, values etc. Tags are used by transformation selectors to select what elements a transformation is applied for.
If a routine has a name, the routine can be shared in its object. A routine is not visible outside its object; object provides its contract only via messages. Access to named and shared routines is provided via routine call operator "@". Defining a routine looks like extracting a procedure from a sequence of statements, but no new elements are created in the object. A routine is defined "in place" where it is implemented and just assigned with some name. After this, the routine can be called from other routines of the object.
May be provide an ability to define a routine as an object member? In this way such routines will be similar to private methods in GPL like C#.
Since routines are defined in place where they are implemented, there is a context (or scope) in which the routine implemented and what names it refers to. All referred names become routine parameters and Paml translator infers parameter names and types from the routine context (messages have parameters by definition).
Routine parameters do not have restrictions like ones for messages: routine parameters can be both objects and/or values when message parameters are strictly objects. This is because calling a routine is always inside an object and cannot cross such boundaries like processes, domains or address spaces.
The example has a layout for IDE feature like displaying a code elements metadata, for instance some properties of routines. Moreover, IDE should display much more metadata information with navigations to the related elements.
Write a comment