Declarative Programs

So far, we have shown code that programmatically creates resumable programs. Those resumable programs are hierarchical arrangements of resumable program statements. Those statements (and their arrangements) can be thought of as an explicit representation of the programmer's intention. That representation ultimately is just data.

Our programs are just data.

Because our mythical runtime only cares about being handed a ProgramStatement object, we can represent the data that constitutes that program however we want.

For instance, the arrangement of statements that constitute the Open, Sesame program can be expressed as data in database tables. One table, shown in Figure 1.2, holds declarations of program statements, now named so that they may be referred to easily.

Figure 1.2. Table of program statements

The data in the second table, shown in Figure 1.3, defines the Statements collection of each composite program statement.

Figure 1.3. Table of program statement composition

The third table, shown in Figure 1.4, holds expressions that can be evaluated when a program statement executes, in order to yield values for that statement's properties.

Figure 1.4. Table of program statement properties

We are declaring the Open, Sesame program, not coding it. Our program clearly does not need to be compiled in order to be run by the mythical runtime. It is simply loaded from the database into a set of ProgamStatement objects and executed.

Alternatively, we could choose a textual representation for Open, Sesame, like this:

 begin   printkey pk1   read r1   printgreeting Key=pk1.Key Input=r1.Text end 

Here too, we only need to write a parser that accepts this text file as input and materializes a ProgramStatementBlock object with the specified collection of contained program statements. This approach of expressing our program in terms of a custom (and constrained) syntax is often called a domain-specific language (DSL). The domain-specific aspect comes from the fact that the DSL grammar contains terms that are specific to a given problem domain. Our program statements are defined as CLR types, so we can simply map the terms in a DSL to these typesthereby turning the parse step into a straightforward deserialization step (initialization of objects).

The .NET Framework 3.0 includes a powerful general-purpose object initialization language (plus associated parsers and serializers) called XAML (eXtensible Application Markup Language).We can use XAML to define Open, Sesame like this:^[6]

^[6] XAML supports property databinding, but we are leaving these details for later chapters.

 <ProgramStatementBlock ... >   <PrintKey ... />   <Read ... />   <PrintGreeting ... /> </ProgramStatementBlock> 

The XAML representation, the custom representation in our invented DSL, and the data in the database tables (and also the ProgramStatementBlock object that is materialized from any of these formats) are isomorphic representations of the same program logic.

Because the mythical runtime is format agnostic, it does not know or care whether we use XAML, database tables, a DSL, or any other means of representing Open, Sesameeven a Tablet PC ink drawing, as shown in Figure 1.5.

Figure 1.5. Tablet PC ink drawing of Open, Sesame program

At last, the control flow of our program is expressed naturally, and now mirrors^[7] the original Open, Sesame console program.

^[7] If we so choose, we can mirror the console program at a more granular level by replacing PrintGreeting with an IfElse composite program statement that contains a (to-be-implemented) Write program statement.