CDA Computational Design and Adaptation

pi: a pattern language

π is a new pattern-based language being developed by the Software Technology group at Technische Universität Darmstadt. In π, there's only one language construct: the pattern. Essentially, a pattern is an EBNF expression that is associated with a meaning. So when writing a π program, you're basically defining both syntax and semantics as you go. This makes it a powerful tool for defining domain-specific languages, and for experimenting with new programming language ideas.

SPARK Ada

SPARK is a carefully defined subset of Ada that comes with a set of tools designed to provide extremely thorough static analysis of SPARK programs. SPARK programs are annotated with additional "contract" information which are also statically checked. SPARK's analyses can detect programming errors such as improper input validation, buffer overflow errors, improper initialization, and information leaks. As a result, it's quite popular in safety-critical and high-integrity systems circles, and makes a good language for developing dependable embedded systems. Adacore has a good tutorial on SPARK that demonstrates some of the ways that SPARK can be used.

Here's a simple example of a SPARK contract for a procedure that increments some variables (derived from here):

procedure Inc (X : in out Integer);
––# global in out CallCount;
––# pre  X < Integer’Last and
––#      CallCount < Integer’Last;
––# post X = X~ + 1 and
––#      CallCount = CallCount~ + 1;

The contract specifies that

• The parameter X and the global variable CallCount must be read by at least one path, and must be updated by at least one path through the procedure.
• Both X and CallCount must be less than the variable Integer'Last prior to execution of the procedure.
• Once the procedure has executed both X and CallCount must have been incremented

SPARK's static analysis tools raise an error if X or CallCount are not read or updated in any path, or if any other global variable is read or updated. Errors will also be raised if there is a possible call to the procedure that violates the precondition, or if the implementation of the procedure won't satisfy the postcondition. Note that all of these things are check statically, not as part of a dynamic check at runtime.

SPARK has been around for quite a while, and has been used in a wide range of industrial projects. So why am I bringing it up now? Because I've just found out that the SPARK language and toolset is now available under the GPL! Which makes it even easier to experiment with SPARK than it was previously.

Vorpal Slot Definitions

Vorpal now has special syntax to streamline slot definition. I hope writing clear Vorpal code will be easier now.  In the past, Vorpal required a highly manual form of slot definition:

x = new()
x.a = new()
x.a.b = 2
x.a[0] = 4

No longer! Now the same result can be achieved with a nicer syntax (and slightly more efficient execution):

x = new(){
   'a' = new(){
      'b' = 2,
      4,
   },
}

Vorpal Labeled Arguments Proposal

Here's a good discussion of how Python's named parameters and Objective-C's interspersed arguments differ:

The named parameters of Python are nice on occasion, because they allow you to specify a few out of many optional arguments, but the major benefit is that arguments can be labeled in either system. I'm sure we've all seen code like the following:

image.show(xPosition, yPosition, -1, true);

What do the last two arguments mean? Of course we could clarify by adding comments or intermediate names:

int offsetBetweenPixels = -1;
bool useOpacity = true;
image.show(xPosition, yPosition, offsetBetweenPixels, useOpacity);
image.show(xPosition, yPosition, -1 /*offsetBetweenPixels*/, true /*useOpacity*/);

Vorpal could easily support labeled arguments. The simplest implementation would take labels ending in a colon and make them part of the method name.