The origins of PFL are buried deep in the past.
The language is of the traditional imperative style, because it fits well with the area of application : it is natural to describe the performance of machines as sequential instructions which have side effects. The basic data structures model machines, and are very like the objects of an object-oriented system in that they contain both local state and procedures proper to the functioning of the object. Typically, the machines are connected hierarchically, again modelling real systems in which factories contain production lines which contain workcells which contain individual machines which themselves may contain distinguishable components.
Rather less conventionally, but still modelling the real systems, any parts of this tree structure may be active at any moment, and the structure is one in which many processes are linked together, possibly sharing global variables, in a form of cactus stack.
The structure is complicated by the need to split stacks from time to time as new local processes are initiated to cater for periodic operations or to await interrupts. These requirements raise interesting questions of the meaning of local and global variables, and the extents of their scopes.
The language itself was originally designed to resemble a formalised human language rather than to fit into an easily compilable pattern, on the principle that ease of use was far more important than an easy job for the compiler writer. Exigencies of time felt most acutely by the successive compiler writers have eroded this principle, but it was an interesting experiment while it lasted.
From the beginning, it was intended that PFL programmes should be distributable over as many processors as might be found necessary or convenient. It was always clear that the hardware configuration was a part of the design, and might not be known during the programme development. Further, as a system evolves, and as the computing hardware available changes, it might be desirable to change the configuration. A PFL programme is therefore a single entity, which can be written and tested as a whole, but can later be split arbitrarily ( subject to obvious constraints of having enough computing capability to do the required jobs ) over any configuration of processors. To make this easier, and to make it possible to use any sort of computer, the language is implemented assuming the use of a virtual machine which can in turn be simulated by software on any conventional computer. In addition, further to provide for the use of different computing hardware, the interface programming is separated from PFL, and dealt with by a separate system. ( That's CBL, the Connection Block Language. ) Questions connected with this distribution of programmes across arbitrary collections of hardware, and of providing satisfactory access to the controlled plant independent of the computer hardware used, are also demanding and of great interest.
Another significant design aim has also been established from the beginning of the PFL development. The unified nature of the PFL programme, its independence of computer hardware type, and the flexibility of the interface with the external world make it possible to provide another useful feature : testing the programme by connecting it to a plant simulator is comparatively straightforward. The machine-independence of the programme means that it can be run either on a distributed system or on a single large machine; the flexibility of the connection-block interface makes it easy to connect to a simulator rather than to the plant.
How much of this has been put into practice ? Not a lot.
Several students have put in some work on PFL :
WORKING NOTES :
Alan Creak,
June, 1998.
Go to me;
Go to Computer Science.