Jobs That Require Prolog

Appeared in Volume 8/1, February 1995

Sanjai Narain

Last year we developed several major applications of Prolog of which I will outline two below. The other two were in formal verification and simulation. Some conclusions which can be drawn are: firstly, it is easier for novices to learn Prolog than expected. An undergraduate student who worked with me, quickly picked up Prolog and went on to develop an advanced GUI for the second project below, without any help from me. (Perhaps he learnt and used Prolog quickly because he was an undergraduate). Secondly, there are many applications where speed is not critical, such as the two below, and for these, Prolog is an excellent candidate. Thirdly, the pervasive skepticism about Prolog has a brighter side: it gives us considerable competitive advantage. Finally, current Prologs are robust and come with a range of support tools, such as an interface to TCP/IP and GUI tools. These are essential if Prolog applications are to operate and be used in the real world.

The first project was a videoconferencing application, built on Bellcore's Touring Machine platform. This platform offers an API in the form of a UNIX process. One can exchange primitive messages with this process for setting up and manipulating videoconferencing calls. These primitive messages need to be assembled into a program to form an "application". I first developed a Prolog interface to this API, using Quintus' TCP/IP interface and a DCG-based program to parse byte stream into API messages (and vice versa). Then, I used Prolog to developed a collection of advanced videoconferencing services such as multiparty calls, call suspend/resume and repeat-dialing. (The methodology was based upon DMOD, a technique for modeling real-time discrete-event systems in Prolog). The entire code was an order of magnitude smaller than equivalent C code. The exercise took me about three months (during which I had to learn about TCP/IP and the API, design the algorithms behind the services, and do the programming). I did not measure efficiency. However, the call set up time was entirely acceptable. For a human it doesn't really matter whether the call is set up in 1 second or 0.1 second. But the 10-fold leeway in speed allows us to use Prolog.

This application involved several tasks for which Prolog was well suited. These included defining action-reaction rules, parsing, constructing and analyzing complex messages and performing inference with call acceptance criteria.

The second application involved generating and automating conformance testing of fiber-optics equipment according to the SONET standard. An undergraduate student, Man-Wing Fong, and I developed a Prolog interface to a Hewlett-Packard SONET instrumentation equipment, using LPA-Prolog. We then programmed a range of advanced tools for collecting and correlating information about SONET equipment, as well as for programmable stress testing of SONET equipment. These tools are all driven via a menu-based user interface. We also generated test-cases for the comprehensive coverage of requirements, computed from a DMOD model of the SONET requirements. The entire project took 11 months. More than 50% of the time was spent understanding SONET and identifying the needs of testers (this latter part is typically quite tough).

Sanjai Narain
Bellcore, Morristown, NJ, USA
Email: narain@thumper.bellcore.com