A call to action
pH is based on over a decade of research in language design for implicit parallelism. During this period, the "look and feel" of the language has evolved significantly as we have increased our understanding of the expressivity issues surrounding topics such as functional arrays, I-structures, M-structures, and sequencing.

The most recent visual change was the adoption of Haskell notation for the functional core, which forms the major part of the language. This change was made both to broaden the appeal of the language to those already familiar with the standard functional language Haskell and to enable leveraging of existing Haskell compiler infrastructures.

Figure 1.11: Layers of pH.

The Haskell programmer should find it very easy to program in pH. There are a few traditional Haskell idioms that cannot be used in pH, but in practice we have found these differences to be very minor.

(An example is the practice in Haskell to generate an "infinite" data structure and examine only a finite part of it. This works in a lazy evaluator for a pure functional language but results in an infinite computation in pH.)

Throughout this period, we have had several research implementations of pH and Id, its predecessor. The current pH implementation is about the third or fourth complete rewrite of the compiler. Earlier implementations were focused on special hardware architectures known as dataflow machines [11], whereas the more recent implementations have focused on stock hardware-first uniprocessors and now SMPs.

Nevertheless, there is always a substantial gap between a research language implementation and a production implementation. There are several bridges to cross before pH can become a widely used production language:

1) Efficient implementations. This is mostly a technical question. Most of the issues concerning efficient implementation of pH are shared with many other high-level programming languages, including Java, and well-known techniques can be applied. A few issues are fairly unique to pH and a few other languages, mostly arising out of the nonstrictness of pH.

2) Interoperability with other languages and systems. This is partly a technical issue, but it is also a social process because it involves standards, interaction models, and the involvement of many constituencies of programmers.

3) Evangelism and market forces. The history of programming languages is replete with examples of languages that did not succeed on technical merits alone. Some recognition that there needs to be some evangelism done to push parallel programming in new directions is already emerging at companies such as Microsoft