On Jun 24, 2008, at 8:53 AM, Peter Lin wrote:
I'm going to disagree that NRL is an anti-pattern.
OK.
It all depends on how you use it.
Agreed... though since I having a tendency to be querolous, I'd change "how" to "when".
I've successfully designed and built custom business rule languages in the past. The key is keeping the domain well defined and narrow.
I am tempted to envy you a bit here (in that the scope has been defined and narrow enough to capture in a DSL, but "interesting" enough to warrant an expert system shell).
Don't try to make a DSL that is a general purpose language.
Agreed. Unfortunately, it's been my experience that there is a significant risk that a customer will drive DSLs inexorably towards a general rule language.
For example, say I want to create a rule language for defining privacy rules for mobile phones.
...<crisp example elided (nothing to quibble about) >...
Once you have enough rules to get a good idea of the scope, you can start designing the language.
Generally at the point the scope is clearly resolved in the projects I'm thinking of, the bulk of the rules work has mostly been done. The rules development coincided with exploring the subject domain with one (or a handful) of experts. The maintenance of the rules that followed been associated with a few experts at most, along with a knowledge engineer, and at fairly low change rates. Changing the rules in a mobile phone privacy system or a message routing system would seem to have a lot more rule-editing users, and a more constrained capability than sendmail + scripting would still be useful without a high risk of scope creep.
Writing the parser is heavily dependent on how solid the DSL is. Once you have the parser, converting to JESS is straight forward.
That seems reasonable. No argument that the parser -> Jess conversion should be mechanical, if a good DSL can be designed. But the effort requires enough users/usage to justify. Some rule patterns can even be simplified into fact assertions, meta- rule to interpret them. OTOH, the problem has to be constrained very well, or this approach can fail in a manner analogous to a overly specific DSL. Perhaps the key is that one must the problem well enough defined before attempting to define a DSL. Analysis first, /then/ DSL design decisions. - Mike -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
