Apologies if i get a bit misty-eyed in the middle, this is a subject dear to me.

My first job involved writing an expert system in VAX Pascal.

It used a list-oriented code/data structures that could be easily serialised for fast store/load.

My main role was writing the search engine part. Initially, we worked hard to build a 'proper' depth-first and breadth-first search engines, but found over time that often, only one rule could fire, or a few independent rules could fire. In these cases, a lot of time and effort was wasted in the 'proper' search mechanisms, and the best (=fastest) way to the result was a combined approach which executed as many independent rules as possible at each stage.

The problem areas were the usual with these sorts of languages, namely Input. You want to minimise the number of questions asked, but what if you backtrack over a question already asked ? Do you ask it again, because the context (to the user) might be different in a different search order. The system also allowed backward-chaining rules if that resulted (as it did sometimes) in a faster result.

P.S. The result was IMHO pretty good. It was used for designing telephone exchanges, which had a certain number of constraints, e.g "given that we want 100 trunk lines and 1000 subscriber lines, how do we layout the exchange in this room ?" Constraints/Rules included trying to make sure units with lots of interconnections were placed close together.

Summary of key issues:

1. You can write a rules-based system in some surprising languages.
2. Input/Output of code/results needs careful design.
3. Handling of input of data/questions needs care.
4. The 'proper' searches are often less efficient than more intuitive searches for many real-world operations.
5. Multiple control-schemes(search-engines) are needed for different problems.
6. Some real-world problems are best solved by rules-based systems !

Hope that provides some food for thought.
--
Brovnik