Home

π: a pattern language

π - not to be confused with the π-calculus - is a pattern-based language being developed by the Software Technology group at Technische Universität Darmstadt. Quoting from the project website:

There is only one language construct in π: the pattern. Patterns are, simply speaking, EBNF-expressions with an associated meaning; a pattern can be easiest understood as a function with a syntactically complex (context-free) "signature". The non-terminal symbols in the signature are then the parameters of the pattern. A π-program is a sequence of instruction symbols (technically, sentences), each being a sequence of (Unicode) characters. The sentences are then evaluated (executed) in the respective order.

The basic idea here seems similar to the OMeta language, previously mentioned on LtU here, but based on EBNF instead of Parsing Expression Grammars (PEGs).

Pattern definitions in π have the form

declare_pattern name ≔ syntax ⇒ type ➞ meaning;

Here's a trivial example of defining a pattern:

declare_pattern
   integer_potentiation ≔ integer:i %W- "^" %W- integer:j ⇒ integer ➞
   {
      int result = i;
      for (int k = 1; k <= j-1; k++)
         result *= i;
      return result;
   };

The resulting pattern can then be used directly in expressions, such as print(42^6);.

More information about the language, as well as the implementation, can be found at http://www.pi-programming.org. There's an OOPSLA09 paper on π as well, but I haven't been able to find an open access version of it yet.

[Update: the π team has made their OOPSLA article available here]

By Allan McInnes at 2009-10-29 01:58 | DSL | Meta-Programming | other blogs | 10072 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Paper?

It's nice that the project website is available two days after the paper was presented, but where is the paper? Unless it is exceptionally well hidden on that site, or in a secret section of their University publication page it doesn't appear to exist on the web. Can somebody supply a copy? At this point I have directly invoked Sod's law: after wasting my time checking the entire site somebody can now point out that it is sitting somewhere obvious that I overlooked....

Moaning aside, this looks very interesting. The example syntax used within the pattern body looks imperative, is this just a consequence of the patterns defined in order to use these constructs? Are there any simple examples with different semantics for the pattern bodies: i.e a more functional or logical example?

By Andrew Moss at Thu, 2009-10-29 13:34 | login or register to post comments

Paper now available

The OOPSLA paper now appears to be available from the project website:

  Roman Knöll and Mira Mezini, "π – a Pattern Language", OOPSLA'09

By Allan McInnes at Fri, 2009-10-30 04:47 | login or register to post comments

unicode

I'm impressed that they had the courage to use non-ASCII characters in their file name... and even more impressed that my system handled it perfectly.

By Samuel Gelineau at Fri, 2009-10-30 16:20 | login or register to post comments

looks like a weaker version of INRIA's Tom for Java

...would have to read the paper to see otherwise.

Tom is a pattern matching compiler extension to Java that preserves the meaning of Java's syntax, but adds a new block-structure called a 'match' construct using the %match keyword.

In particular, Tom is more powerful than Scala's pattern matching constructs (but the power is less useful, because you are programming the handlers in Java and not using Scala's functional programming style features).

Like Pi, you can write for-loops and other Java-style code to handle matches.

Here is a video of using Tom for JPA. Clicky.

By Z-Bo at Thu, 2009-10-29 15:54 | login or register to post comments

what?

This is the first time I've heard of either π or Tom, but just looking at the given π example and the Tom video makes it utterly clear that the systems are completely different. Except for the fact that they both use the word "pattern", with two rather different meanings.

By "pattern", Tom seems to mean "pattern-matching", that is, branching on the runtime values of some variables, using patterns to concisely express the conditions in which each branch is executed.

By "pattern", π seems to mean "template", that is, replacing all future occurrences of a particular keyword with its definition. The innovation seems to be that instead of using a rigid syntax à la Lisp, like (keyword arg1 arg2), π allows the parser to be extended with arbitrary BNF expressions, like "(" "keyword" integer:arg1 integer:arg2 ")".

By Samuel Gelineau at Fri, 2009-10-30 16:14 | login or register to post comments

You're right. After reading

You're right.

After reading the paper, it's more clear.

What threw me off was the print(42^6) code at the bottom of the Allan's original LtU summary. I assumed that came from a host language, and so assumed this pattern matching was more like Tom than OMeta.

The innovation seems to be that instead of using a rigid syntax à la Lisp, like (keyword arg1 arg2), π allows the parser to be extended with arbitrary BNF expressions, like "(" "keyword" integer:arg1 integer:arg2 ")".

Actually, Carl Sassenrath did this in 1993, with REBOL, so the innovation is really just providing an EBNF solution instead of a PEG solution. With OMeta supporting left direct recursion, this does not seem to be a huge innovation?

By Z-Bo at Mon, 2009-11-02 16:01 | login or register to post comments

How does it relate to pattern calculus ?

How does it relate to pattern calculus ? (http://bondi.it.uts.edu.au/)
PI is dynamic but otherwise how does it compare to Bondi ?
Is it pure pattern calculus rather than typed pattern calculus or something entirely different ?
(sorry i am just too dumb to figure)

My comment to language designers:

Related ideas and similar languages is not a good enough reference, you have to explicitly base your design on a well documented calculus / rewriting system theory. Otherwise the reader has a hard time just to figure out what the ground framework is. Pattern oriented design and post-paradigmatic language do not qualify here, because it sounds too much like buzzwords.

By Damien Guichard at Fri, 2009-10-30 15:23 | login or register to post comments

How does this compare to Katahdin?

A cursory glance at the example provided here and the one accompanying the LtU article on Katahdin (http://lambda-the-ultimate.org/node/2303) strikes me as somewhat similar.

Has anyone had the time to play with both?

By drinkinglizard at Tue, 2009-11-03 13:54 | login or register to post comments

A few differences

The obvious point of difference is that Katahdin (like OMeta) uses PEGs, whereas π uses EBNF to define patterns. How important that difference is isn't really clear to me. At a more philosophical level, Katahdin allows you to "...define new language constructs such as expressions and statements as easily as new types or functions...", so there are (at least) both functions and additional languages constructs. In contrast, π is based on the notion that everything is a pattern - if a "function" exists, it's a pattern as well. How much difference that would actually make in practice, I couldn't say. It seems likely that π's model is somewhat closer to the pattern calculus mentioned above (although I haven't really looked at exactly what the relationship is) and thus might more directly support formal analysis.

By Allan McInnes at Tue, 2009-11-03 21:49 | login or register to post comments