|XP is just a number|
In college, a programming assignment was to write an inference engine in Pascal. Although everyone else in class thought it was a huge deal (a semester-long project) and turned in huge monstrosoties of programs, I thought it was a simple, beautiful, elegant problem, and made a 5-page solution.
So, I think it's easy enough to implement reusable logic to go through a fact base. It would be easy to represent the facts in Perl, too.
The cool thing that Prolog does is "variable unification", and Perl has nothing like that. There was a Perl6 RFC that was dismissed as being too complex and still not complete enough to be worthwhile, and I reciently read about the backtracking scope in the new regex and wondered if that might be made more general, but it's not really the same thing.
I wonder, though, if full-blown Unification is needed to solve the problems with an inference-engine approach. The big deal about it is that it makes tail-end recursion possible (e.g. no cleanup step after the call returns), while doing the same thing with "undo" code living on the stack would mean you really do need to keep a stack of everything you've been though. Today machines have millions of times more storage, so is that an issue?
Also, you would want "how" and "why" features on your inference engine.
You have your fundimental facts and your rules stored in different ways—lists and subs. The subs are hand-written. How is that reusable? I think it illustrates a "pattern" commonly found in code, to solve a complex problem in a top-down manner.
However, I think it would be more interesting to start by expressing your rules as Perl data, in a simple and natural manner:
and come up with a fully reusable function that takes this data and makes inferences on it. Here, I used '$X' etc. as placeholders, like variables in Prolog or the questionmark stuff in CLIPS. Seems like you could generate source code on the fly based on the rule!