Real-time control languages.

How it started.

( This first bit is a self-indulgent stroll down memory lane. If you're not interested in my reminiscences, skip. )

I've been interested in computer control systems for quite a long time. I pondered on the first ideas while I was working towards my Ph.D. degree. At that time, I was still a chemist, but I knew enough about computers to be aware of their general abilities. The practical part of my research was carried out on a large vacuum system, in which gases were moved from place to place by manipulating taps, pumps, liquid nitrogen, and other such devices. The experiment involved mixing certain quantities of gases, heating them in a furnace to a set temperature, illuminating the mixture for a controlled time, and then analysing the products. And then doing it again, with slightly different condition. And again. And again. And ....

Each experiment took between two and three hours, and involved exactly no intellectual activity, so I had lots of time to think about how this sheer waste of time could be avoided. The purely routine sequence of actions with minor systematic variations was obviously the ideal task for a computer, and I thought about it for some time. But I knew enough about computers to know that I knew hardly anything about computers, so never felt brave enough to follow it up. ( In hindsight, I was wrong. I suspect that I knew at least as much about computers as many people who pontificated about them at the time - or now, for that matter - but modesty has always been one of my few engaging characteristics. )

So nothing happened, and the idea lay fallow until I arrived in Auckland, and Peter Sergent expressed interest in a Ph.D. programme in some such field. By that time, there had been some practical implementations of experiment control systems, but we knew of no systematic development of languages specially designed for the job, so my interest in languages for control systems was born, the PFL saga began, and the rest ( as they say ) is history.

Apart from PFL, history didn't do much for quite some time, but the interest continued. It emerged again when Steven Lomas, a final-year student intending to go on to postgraduate studies, was looking for interesting courses for his M.Sc.. The result, after another nostalgic story, was the emergence in 1986 of the postgraduate course called Robotics and real-time control.

The result of the course was a trickle of students with some interest in continuing to further studies in control systems - usually in the form of an M.Sc. thesis.

One of these, Mark Brodsky, began the PDL saga. He took a holiday job with Fisher and Paykel ( hereinafter denoted by F&P; their contributions to the project and support are hereby acknowledged with thanks ) in the 1989-1990 summer vacation, where he was programming for their assembly line control system, and liked it. He told me that he might like to do something of the sort for his thesis. I was still less than completely confident that I was sufficiently knowledgable to cope with real industry, but didn't want to miss the opportunity if it was one, so I suggested that if he could set up some meetings with appropriate F&P people we could explore the possibility. He did, we carried on, and the embryo of PDL emerged from his work.

Since then, PDL has received much more attention from various students than has PFL. I'm not sure why; PDL is a lot simpler, and perhaps shows more originality, but PFL is based on a more interesting model of computation. I think.

What it's about.

PFL is a rather traditional programming language with a noticeable, though accidental, resemblance to Pearl, but based on a rather interesting cactus stack structure.

PDL is very different, being a strongly state-oriented language emphasising flexible and adaptable syntax.

Roger Kay and I tried to compare the two, with much confusion but a few interesting conclusions.

So far, neither has been adequately explored.

Alan Creak,
June, 1998.

Go to me;
Go to Computer Science.