Implementing the $\lambda _{GT}$ Language: A Functional Language with Graphs as First-Class Data

Abstract

Several important data structures in programming are beyond trees; for example, difference lists, doubly-linked lists, skip lists, threaded trees, and leaf-linked trees. They can be abstracted into graphs (or more precisely, port hypergraphs). In existing imperative programming languages, these structures are handled with destructive assignments to heaps as opposed to a purely functional programming style. These low-level operations are prone to errors and not straightforward to verify. On the other hand, purely functional languages allow handling data structures declaratively with type safety. However, existing purely functional languages are incapable of dealing with data structures other than trees succinctly. In earlier work, we proposed a new purely functional language, $\lambda _{GT}$, that handles graphs as immutable, first-class data structures with pattern matching and designed a new type system for the language. This paper presents a prototype implementation of the language constructed in about 500 lines of OCaml code. We believe this serves as a reference interpreter for further investigation, including the design of full-fledged languages based on $\lambda _{GT}$.

J. Sano—Currently with NTT Laboratories.

Appendix

Our implementation consists of about 500 lines of OCaml code as shown in Table 1.² This is about half the size of the reference interpreter of the graph transformation-based language GP 2 [1], which is about 1,000 lines of Haskell code [2].

Table 1. LOC of the interpreter.

Figure 7 gives the concrete syntax of the language we have implemented. Comments start at %. As usual, let defines a variable that has a value on the right-hand side of =, if $n = 0$. If $n \ge 1$, this defines a curried $n$-ary function. Recursive $n$-ary functions can be defined with let recs. We designed a syntax that is easy to parse and did not yet implement the term-notation abbreviation. We do not intend to provide a full-fledged language but to study the feasibility of the language with a concise implementation.

Fig. 7.

Concrete syntax of $\lambda _{GT}$.

The examples in Sect. 3 are concerned with difference lists, which are powerful and useful data structures, and we have shown the composition and the decomposition of these structures. However, the graphs and their operations in $\lambda _{GT}$ are not limited to them.

Fig. 8.

Map a function to the leaves of a leaf-linked tree.

Fig. 9.

Leaf-linked trees.

Fig. 10.

Dataflow graph (factorial of $n$).

For operations that cannot be performed by simply decomposing and composing graphs, we can use some atoms as markers for matching. For example, a map function that applies a function to the elements of the leaves of a leaf-linked tree can be expressed as Fig. 8. If is a successor function and we have bound the graph of Fig. 9 (a) to , evaluating the program will return the graph of Fig. 9 (b). Figure 11 shows the demo of the program. Figure 11 (a) is the view obtained by pressing the Run button after filling in the code. Figure 11 (b)–(g) shows each graph at the breakpoints, from which computation can be resumed with the Proceed button.

Fig. 11.

Demo of mapping a function to the leaves of a leaf-linked tree.

$\lambda _{GT}$ is capable of handling graphs that include functions. Figure 10 illustrates a dataflow graph that calculates the factorial of an input number. The graph has input and output links from and to the outside and functions at the nodes. There are two kinds of nodes; nodes with an input and an output, and a node with an input and two outputs (a branch). This can be written as Fig. 12, lines 2–28, in $\lambda _{GT}$.

The evaluator of such a dataflow graph is shown in Fig. 12, lines 31–52. We use a marker M to trace the value on the flow (lines 53–54). Lines 33–37 deal with a node with an input and an output (N2). They apply the embedded function to the value. Lines 39–45 deal with a node with an input and two outputs (N3). They decide which way to go by applying the embedded function to the value. Line 47 terminates the evaluator when the marker is pointing at the output link _Out. We have run the code on our interpreter and checked that the interpreter returns {120(_Z)} ($= 5!$) after printing 14 intermediate graphs.

Fig. 12.

Embedding a dataflow language in $\lambda _{GT}$.

We can even build a larger dataflow from components. For example, we can compose the graph connecting the output and the input of them: {nu _X. (dataflow[_In,_X],dataflow[_X,_Out])}. Applying {run[_Z]} to {3(_Z)} and the graph returns {720(_Z)} ($= (3!)!$).