Local Modules in Imperative Languages

TL;DR

This paper introduces local modules for imperative languages, allowing temporary module inclusion during execution, which enhances code reuse and heap management, demonstrated through an extension of C called C^{mod}.

Contribution

It proposes a novel local module mechanism with a new implication statement, enabling efficient, temporary module management in imperative languages.

Findings

Introduced a new implication statement for local modules.

Extended C with local modules called C^{mod}.

Improved heap management scheme for traditional languages.

Abstract

We propose a notion of local modules for imperative langauges. To be specific, we introduce a new implication statement of the form $D \supset G$ where $D$ is a module (i.e., a set of procedure declarations) and $G$ is a statement. This statement tells the machine to add $D$ to the program in the course of executing $G$. Thus, $D$ acts as a local module and will be discarded after executing $G$. It therefore provides efficient module management. We illustrate our idea via C^{mod}, an extension of the core C with the new statement. In addition, we describe a new constructive module language to improve code reuse. Finally, we describe a scheme which considerably improves the heap management in traditional languages.

Equations

$$(p=\mathrm{new}obj)\supset G$$

Full text

{summary}

We propose a notion of local modules for imperative langauges. To be specific, we introduce a new implication statement of the form $D\supset G$ where $D$ is a module (i.e., a set of procedure declarations) and $G$ is a statement. This statement tells the machine to add $D$ $temporarily$ to the program in the course of executing $G$. Thus, $D$ acts as a local module and will be $discarded$ after executing $G$. It therefore provides efficient program management. In addition, we describe a new constructive module language to improve code reuse. Finally, we describe a scheme which improves the heap management in traditional languages. We illustrate our idea via Cmod, an extension of the core C with the new statement.

1 Introduction

Efficient program management in imperative programming – C, its extension [4] and Java – is an important issue. Yet this has proven a difficult task, relying on ad-hoc techniques such as various cache/page replacement algorithms.

An analysis shows that this difficulty comes from the fact that the machine has no idea as to which modules are to be used in the near future. Therefore module management can be made easier by making the programmer specify which modules are to be used. Toward this end, inspired by [6, 5, 7], we propose a new implication statement $D\supset G$, where $D$ is a set of procedure declarations and $G$ is a statement. This has the following execution semantics: add $D$ temporarily to the current program in the course of executing $G$. In other words, the machine loads $D$ to the current program, executes $G$, and then unloads $D$ from the current program. This implication statement is closely related to the $let$-expression in functional languages and the implication goals in logic languages [6, 7].

Thus $D$ acts as $local$ procedures to $G$ in that $D$ is hidden from the rest. Our approach calls for a new runtime stack called program stack, as it requires run-time loading and unloading. It follows that local procedures in our language is (stack) dynamic scoped in the sense that the meaning of a procedure is always determined by its most recent declaration. On the other hand, most modern languages allow local procedures within nested procedures. These approaches are based on static scoping in granting access and requires no run-time loading and unloading. The main advantages of our approach is the following:

• (1) 

It allows local procedures at the statement level, whereas other languages allow local procedures only at the procedural level. Thus our langauge provides the programmer more flexibility.

• (2) 

It leads to efficient program/memory management due to loading and unloading. This is not negligible when local procedures are big.

• (3) 

It has a simple, natural syntax and semantics due to dynamic scoping of local procedures. In contrast, it is well-known that other systems have awkward and complicated semantics mainly due to static scoping. Consequently, these systems are very difficult to read, write, implement and reason about.

On the negative side, it requires a little run-time overhead for loading and unloading.

In the sequel, a module is nothing but a set of procedures with a name. Our notion of local procedures extends to a notion of local (occurrences of ) modules in a straightforward way. That is, we propose a new module implication statement $/m\supset G$, where $m$ is a module name and $G$ is a statement. This has the following execution semantics: add a (local occurrence of) module $m$ temporarily to the current program in the course of executing $G$. Note that our modules are stack dynamic in the sense that they are loaded/unloaded in the program in a stack fashion. This leads naturally to the dynamic scoping for procedure names. In contrast, most imperative languages have a module language which is typically based on the notion of static modules with no run-time loading and unloading, leading naturally to static scoping. It is well-known that static scoping causes the naming problem among procedures across independent modules.

Our module system has some advantages over other popular module systems in imperative languages.

• (1) 

It allows the programmer to load and unload other modules due to the module implication statement. This leads to the dynamic scoping for procedure names. In contrast, this is traditionally impossible in other languages, leading to the static scoping and the naming problem.

• (2) 

Dynamic scoping leads to a simple, natural syntax and semantics, as there is no naming problem.

• (3) 

As we shall see later, it allows mutually recursive modules thanks to dynamic scoping.

In addition, we add a novel module language to improve code reuse. Finally, we propose a variant of the implication statement which considerably simplifies the heap management.

This paper extends a C-like language with the new implication statement. We focus on the minimum core of C. The remainder of this paper is structured as follows. We describe Cmod, an extension of C with a new statement in Section 2. In Section 3, we present an example of Cmod. In Section 4, we describe a constructive module language for enhancing code reuse. In Section 5, we propose a scheme that improves the heap management. Section 6 concludes the paper.

2 The Core Language

The language is core C with procedure definitions. It is described by $G$- and $D$-formulas given by the BNF syntax rules below:

[TABLE]

In the above, $A$ represents a head of a procedure declaration $p(x_{1},\ldots,x_{n})$ where $x_{1},\ldots,x_{n}$ are parameters. A $D$-formula is a set of procedure declarations. In the transition system to be considered, a $G$-formula will function as a statement and a list of $D$-formulas enhanced with the machine state (a set of variable-value bindings) will constitute a program. Thus, a program is a pair of two disjoint components, i.e., $\langle D_{1}::\ldots::D_{n}::nil,\theta\rangle$ where $D_{1}::\ldots::D_{n}::nil$ is a stack of $D$-formulas and $\theta$ represents the machine state. $\theta$ is initially empty and will be updated dynamically during execution via the assignment statements.

We will present an interpreter for our language via natural semantics [3]. Note that our interpreter alternates between the execution phase and the backchaining phase. In the execution phase (denoted by $ex({\cal P},G,{\cal P}^{\prime})$), it executes a statement $G$ with respect to ${\cal P}$ and produce a new program ${\cal P}^{\prime}$ by reducing $G$ to simpler forms. The rules (6)-(9) deal with this phase. If $G$ becomes a procedure call, the machine switches to the backchaining mode. This is encoded in the rule (5). In the backchaining mode (denoted by $bc(D,{\cal P},A,{\cal P}^{\prime})$), the interpreter tries to find a matching procedure for a procedure call $A$ inside the module $D$ by decomposing $D$ into a smaller unit (via rule (4)-(5)) and reducing $D$ to its instance (via rule (2)) and then backchaining on the resulting definition (via rule (1)). To be specific, the rule (2) basically deals with argument passing: it eliminates the universal quantifier $x$ in $\forall xD$ by picking a value $t$ for $x$ so that the resulting instantiation, $[t/x]D$, matches the procedure call $A$. The notation $S$ seqand $R$ denotes the sequential execution of two tasks. To be precise, it denotes the following: execute $S$ and execute $R$ sequentially. It is considered a success if both executions succeed. Similarly, the notation $S$ parand $R$ denotes the parallel execution of two tasks. To be precise, it denotes the following: execute $S$ and execute $R$ in any order. It is considered a success if both executions succeed. The notation $S\leftarrow R$ denotes reverse implication, i.e., $R\rightarrow S$.

Definition 1**.**

Let $G$ be a statement and let ${\cal P}$ be the program. Then the notion of executing $\langle{\cal P},G\rangle$ and producing a new program ${\cal P}^{\prime}$– $ex({\cal P},G,{\cal P}^{\prime})$ – is defined as follows:

• (1) 

$bc((A=G_{1}),{\cal P},A,{\cal P}_{1})\ \leftarrow$* *

$ex({\cal P},G_{1},{\cal P}_{1})$. % A matching procedure for $A$ is found.

• (2) 

$bc(\forall xD,{\cal P},A,{\cal P}_{1},)\ \leftarrow$* *

$bc([t/x]D,{\cal P},A,{\cal P}_{1})$. % argument passing

• (3) 

$bc(D_{1}\land D_{2},{\cal P},A,{\cal P}_{1})\ \leftarrow$* *

$bc(D_{1},{\cal P},A,{\cal P}_{1})$. % look for a matching procedure in $D_{1}$.

• (4) 

$bc(D_{1}\land D_{2},{\cal P},A,{\cal P}_{1})\ \leftarrow$* *

$bc(D_{2},{\cal P},A,{\cal P}_{1})$. % look for a matching procedure in $D_{2}$

• (5) 

$ex({\cal P},A,{\cal P}_{1})\ \leftarrow$* $(D_{i}\in{\cal P})$ parand $bc(D_{i},{\cal P},A,{\cal P}_{1})$, provided that $D_{i}$ is the first module in the stack, which contains a declaration of $A$. % $A$ is a procedure call*

• (6) 

$ex({\cal P},true,{\cal P})$. % True is always a success.

• (7) 

$ex(\langle{\cal S},\theta\rangle,x=E,\langle{\cal S},\theta\uplus\{(x,E^{\prime})\}\rangle)\leftarrow$* $eval({\cal P},E,E^{\prime})$. *

% evaluate $E$ to get $E^{\prime}$. Here, $\uplus$ denotes a set union but $(x,V)$ in $\theta$ will be replaced by $(x,E^{\prime})$.

• (8) 

$ex({\cal P},G_{1};G_{2},{\cal P}_{2})\ \leftarrow$* *

$ex({\cal P},G_{1},{\cal P}_{1})$* seqand $ex({\cal P}_{1},G_{2},{\cal P}_{2})$. % a sequential composition*

• (9) 

$ex(\langle{\cal S},\theta\rangle,D\supset G_{1},{\cal P}_{1})\ \leftarrow$* *

$ex((\langle D::{\cal S},\theta\rangle,G_{1},{\cal P}_{1})$. % add $D$ to the top of the program stack ${\cal S}$.

• (10) 

$ex(\langle{\cal S},\theta\rangle,/m\supset G_{1},{\cal P}_{1})\ \leftarrow$* *

$ex((\langle D::{\cal S},\theta\rangle,G_{1},{\cal P}_{1})$. % add $D$ to the top of the program stack ${\cal S}$.

If $ex({\cal P},G,{\cal P}_{1})$ has no derivation, then the interpreter returns the failure. The rule (9) deals with the new feature.

3 Examples

In our language, a module is simply a set of procedures associated with a name. Below the keyword $module$ associates a name to a $D$-formula. The following module Emp has a procedure Age which sets the variable named $age$, whose value represents the employee’s age. Similarly, the module Bank is defined with the procedures Deposit, Withdraw, Balance.

[TABLE]

[TABLE]

Now consider executing the following main statement $G$ from an empty program.

[TABLE]

Execution proceeds as follows: Initially the program is empty. Then, the machine loads the module $Emp$ to the program, printing the ages of three employees – Tom, Kim and Sue –, and then unloads the module $Emp$. Then, the machine loads the module $Bank$ to the program, deposits $100 to Tom’s account, and then unloads the module$Bank$. Note that the module$Emp$is available to the first task only, while$Bank$ to the second task only.

As the second example, let us consider two mutually recursive modules $Ev$ and $Od$. The module $Ev$ has a procedure Even(x) which returns true if x is even. Similarly, the module $Od$ is defined with the procedure Odd(x).

[TABLE]

[TABLE]

Now consider executing even(9) from the module Ev. Execution proceeds as follows: Initially the program is empty. Then, the machine loads the module $Emp$ to the program, printing the ages of three employees – Tom, Kim and Sue –, and then unloads the module $Emp$. Then, the machine loads the module $Bank$ to the program, deposits $100 to Tom’s account, and then unloads the module$Bank$. Note that the module$Emp$is available to the first task only, while$Bank$ to the second task only.

4 A Constructive Module Langauge

Modern languages typically support code reuse via inheritance. We propose a constructive approach to code reuse as an alternative to inheritance. To begin with, our language provides a special macro function $/$ which binds a name to a set of method (and constant) declarations. This macro function serves to represent programs in a concise way. For example, given two macro definitions $/p\ =\ f(x)=x$ and $/q\ =\ g(x)=0$, the notation $/p\land/q$ represents $f(x)=x\land g(x)=0$. Here $\land$ means the accumulation of two modules.

In addition to $\land$, our module language provides a renaming operation of the form $ren(b,a)D$ which replaces $b$ by $a$ in a module $D$ and $\forall xD$ for universal generalization. There are other useful operations such as $private\ f\ D$ (reuse $D$ with making $f$ private) and $shareD$ (reuse D via sharing, not copying) but we will not discuss them further here.

Now let us consider macro processing. Macro definitions are typically processed before the execution but in our setting, it is possible to process macros and execute regular programs in an interleaved fashion. We adopt this approach below.

We reconsider the language in Section 2.

[TABLE]

In the above, $n$ is a name and $A$ represents a head of a procedure declaration $p(x_{1},\ldots,x_{n})$ where $x_{1},\ldots,x_{n}$ are parameters. A $D$-formula is a set of procedure declarations. An $M$-formula is called macro definitions and ${\cal M}$ is a list of $M$-formulas. In the transition system to be considered, a $G$-formula will function as a statement and a list of $D$-formulas, a list of $M$-formulas and the machine state (a set of variable-value bindings) will constitute a program. Thus, a program is a pair of three disjoint components, i.e., $\langle D_{1}::\ldots::D_{n}::nil,{\cal M},\theta\rangle$ where $\theta$ represents the machine state. $\theta$ is initially empty and will be updated dynamically during execution via the assignment statements.

Definition 2**.**

Let $G$ be a statement and let ${\cal P}$ be the program. Then the notion of executing $\langle{\cal P},G\rangle$ and producing a new program ${\cal P}^{\prime}$– $ex({\cal P},G,{\cal P}^{\prime})$ – is defined as follows:

• (1) 

$bc((A=G_{1}),{\cal P},A,{\cal P}_{1})\ \leftarrow$* *

$ex({\cal P},G_{1},{\cal P}_{1})$. % A matching procedure for $A$ is found.

• (2) 

$bc(\forall xD,{\cal P},A,{\cal P}_{1},)\ \leftarrow$* *

$bc([t/x]D,{\cal P},A,{\cal P}_{1})$. % argument passing

• (3) 

$bc(D_{1}\land D_{2},{\cal P},A,{\cal P}_{1})\ \leftarrow$* *

$bc(D_{1},{\cal P},A,{\cal P}_{1})$. % look for a matching procedure in $D_{1}$.

• (4) 

$bc(D_{1}\land D_{2},{\cal P},A,{\cal P}_{1})\ \leftarrow$* *

$bc(D_{2},{\cal P},A,{\cal P}_{1})$. % look for a matching procedure in $D_{2}$

• (5) 

$bc(ren(a,b)D,{\cal P},A,{\cal P}_{1})\ \leftarrow$* *

$bc([b/a]D,{\cal P},A,{\cal P}_{1})$. % renaming operation

• (6) 

$bc(/n,{\cal P},A,{\cal P}_{1})$* if $bc(D,{\cal P},A,{\cal P}_{1})$ and $(/n=D)\in{\cal M}$. % we assume it chooses the most recent macro definition.*

• (7) 

$ex({\cal P},A,{\cal P}_{1})\ \leftarrow$* $(D_{i}\in{\cal P})$ parand $bc(D_{i},{\cal P},A,{\cal P}_{1})$, provided that $D_{i}$ is the first module in the stack, which contains a declaration of $A$. % $A$ is a procedure call*

• (8) 

$ex({\cal P},true,{\cal P})$. % True is always a success.

• (9) 

$ex(\langle{\cal S},{\cal M},\theta\rangle,x=E,\langle{\cal S},{\cal M},\theta\uplus\{(x,E^{\prime})\}\rangle)\leftarrow$* $eval({\cal P},E,E^{\prime})$. *

% evaluate $E$ to get $E^{\prime}$. Here, $\uplus$ denotes a set union but $(x,V)$ in $\theta$ will be replaced by $(x,E^{\prime})$.

• (10) 

$ex({\cal P},G_{1};G_{2},{\cal P}_{2})\ \leftarrow$* *

$ex({\cal P},G_{1},{\cal P}_{1})$* seqand $ex({\cal P}_{1},G_{2},{\cal P}_{2})$. % a sequential composition*

• (11) 

$ex(\langle{\cal S},{\cal M},\theta\rangle,D\supset G_{1},{\cal P}_{1})\ \leftarrow$* *

$ex((\langle D::{\cal S},{\cal M},\theta\rangle,G_{1},{\cal P}_{1})$. % add $D$ to the top of the program stack ${\cal S}$.

• (12) 

$ex(\langle{\cal S},{\cal M},\theta\rangle,/n:M\supset G_{1},{\cal P}_{1})$* if $ex(\langle/n::{\cal S},M::{\cal M},\theta\rangle,G_{1},{\cal P}_{1})$ % Add new macros to the front of ${\cal M}$. Here $::$ is a list constructor.*

If $ex({\cal P},G,{\cal P}_{1})$ has no derivation, then the interpreter returns the failure.

5 Improving Heap Management

Our earlier discussions in Section 2 are based on dynamic procedure binding. More interestingly, our notion of implication statements can be applied equally well to static procedure/data binding.

To be specific, allocation and deallocation of (heap) objects – and accessing them through pointers – occur frequently in traditional imperative languages with static procedure/data binding. This includes malloc-free for memory management, new-dispose for objects, new-delete for heap objects (arrays, records, etc). Unfortunately, allocation and deallocation constructs are unstructured. Using allocation and deallocation carelessly leads to serious problems.

Towards an efficient yet robust memory management, we need to impose some restrictions on the use of allocation and deallocation by providingng a high-level statement. To be specific, we propose to use the following $pointer$-$implication$ statement of the form

[TABLE]

where $p$ is a pointer and $obj$ is a program object or a data object (arrary, record, $etc$). This is a variant of the implication statement in Section 1 with the following semantics: It creates an object $obj$ with $p$ being a pointer to $obj$, executes the statement $G$ and then deallocate $obj$ and $p$. To avoid additional complications, we assume that pointers can only be initialized but not manipulated.

The following code is an example where arrayptr1 and int[100] are available in both the statements $S_{1}$ and $S_{2}$, while arrayptr2 and int[1000] are available only in $S_{2}$.

[TABLE]

Our system requires considerable change to memory management: it needs to maintain three different categories of memory: program/data stack, run-time stack and the heap. Program/data stack is a new component and it – instead of the heap – is used to maintain program/data objects created via the $new$ construct. Thus it replaces most of the works done by the heap. Program/data stack has considerable advantages over the heap: it is more efficient and can simplify several complications caused by the heap including garbage collection, heap fragmentation, and dangling pointers.

6 Conclusion

In this paper, we have proposed a simple extension to imperative languages. This extension introduced an implication statement $D\supset G$ where $D$ is a module and $G$ is a statement. This statement makes $D$ local to $G$. It therefore maintains only the active modules in the current program context.

7 Acknowledgements

This work was supported by Dong-A University Research Fund.