At this point, it's merely for the purposes of "because it (the lack of perl&rules) is there". Mind you, yes, I'm thinking down the road and making this professional quality, which means that I have to consider the audience at that point. But the initial proof-of-concept would be a working rules engine, in which simply flow control is directed by what facts; anything beyond that , such as how facts are formatted, how rules are defined, etc, is mostly the 'user interface' part of the problem. And by providing a working engine, weaknesses and strengths of the interface can be figured out faster.

I guess my overall goal is to provide a way to run a rules-like system (which in my previous experience has had weak interaction with the OS outside of input and output to terminal) using perl (which has strong OS interaction including networking, etc). An ultimate use would to place a perl script with the rules engine at the backend of a network socket, such that new facts can be introduced remotely and actions on local and remote systems taken as such (a so-called business logic server); so the language and depth would have to be simple enough to write the rules in but still allow for taking full advantage of using perl. There's obvious approaches to doing this, but determining how to draw the line between perl-isms and language elements I can introduce is way down the road.

Once I get moving on this, I'll be posting the code as I've done with other modules of mine here for feedback and such, at least until it's stable and usable enough for CPAN inclusion.

---

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain