Analysis of the Functional Rule-Based

The design, implementation, and execution of the functional rule-based system is a feasibility study of the practical use of functional programming from both a programming and an execution viewpoint. The programming viewpoint is a test to see if a large state-based application can be written effectively in a functional language. The execution viewpoint is a test to see if the functional application can be used on a day-to-day basis.

The functional rule-based system uses a simple non state-saving matching algorithm which has polynomial behaviour. This rule-based system consists of 5 main components:

i) the compiler

writing this re-enforced the view that recursive compilers are easy to build in functional languages. Much work has been done on functional languages and compilation as seen in section 3.3. This compiler is a simple recursive-decent compiler for a non-left recursive grammar.

ii) the matcher

this is the core of a rule-based system. This matcher uses a simple non state-saving algorithm whereby every clause of every rule is matched against every working memory element on every cycle. As stated, its behaviour is poor.

iii) the run-time system

this is the framework for the functional 0PS5. It arranges for input and output to the program and binds the compiler and matcher together. It manipulates a large state object, which has all the data required by the program, such as production memory and working memory.

iv) act

v) conflict resolution

this uses a pipeline of functions to emulate an ordered list of instructions There is a general misconception amongst imperative programmers that functional languages are unable to deal with state. This thesis refutes this claim with the proof of a working application. In this chapter a technique was demonstrated for writing applications which manipulate state. This technique combines using an abstract data type to represent state with a set of higher-order State State functions. By using this technique, 90% of the rule-based system OPS5, which is an inherently state-saving application, has been successfully implemented.

Due to the desire to keep the compiler simple, the initial version of the compüer does not include error reporting or error recovery. Although this is sufficient for a prototype compiler, further work would be the implementation of a second version in which the lexical analyser and the parser support both error reporting and error recovery.

The fact that a functional language is being used to implement 0PS5 presents both advantages and disadvantages. Depending on ones point of view the advantages for one person may be the disadvantages of another and we see that they are the same. The disadvantage is that state must be represented explicitly and therefore the code must be redesigned. As all state is explicit, the program code can look messy and thus lose the functional expressiveness that is expected. Imperative programs look much the same when state is added because state manipulation is implicit. The advantage is that state must be represented explicitly and therefore the code must be redesigned. There is explicit control over which parts of the state are passed and accessed, therefore implict state manipulation and generally accessible global store issues are overcome. Furthermore, an imperative implementation allows error reporting to be added as an afterthought. This has the disadvantage that error reporting and error recovery may suffer from incoherent design. In a functional system, error reporting and error recovery must be explicitly designed into the system.

Limitations of the Functional 0PS5

The rule-based system created for this thesis is limited in comparison to the LISP version of OPS5. Only the main actions have been implemented, and the compiler is somewhat limited, giving few error messages and being unforgiving when errors do occur. These limitations have not been a problem because the original LISP system gives good error messages and can be used as a benchmark for any testing done. A group at Camegie-Mellon University has implemented OPS5 in C. Their implementation has limitations which are similar to those found in the functional 0PS5. This is because both Miranda and C treat programs and data differently, whereas LISP treats them the same.

In the functional OPS5 there are problems with: • doing I/O, as seen previously.

• bugs buried deep in the system which were hard to find, because of a lack of debugging tools.

• measuring the performance of the system. Because neither the time spent in functions nor the space used can be measured, it is impossible to compare this system with other implementations of 0PS5.

Benefits of Functional Programming

The features of strong typing, the creation of new data types, and higher-order functions in functional languages make applications such as compilers easier to write than in imperative languages. Pipelining (via function composition) aids in the building of algorithms, for example:

• in the compiler, the data types used for the simple 0PS5 matcher were extended by adding new functions to convert the structure into a new form. The code for the original compiler was untouched.

• in the conflict resolution, each section of the definition was converted to its own function. These functions were given their own data type and then combined in a pipeline to form a working algorithm.

In general the use of pipelining and abstract data types are an effective way to write large programs. The term pipelining rather than function composition is used because it is possible to impose an abstract framework on the program which looks like function composition but is not. For example, monads may be used to pipeline functions, as will be seen in chapter 4. Expressions can be arbitrarily complex, and can be easily combined with one another. In imperative languages, there are commands and expressions which cannot be easily combined because expressions return values and commands do operations. Functional languages present a uniformity to the programmer.