hmm i would ask you to explain but you cant 🙂

When I've looked at rule engines, I start seeing them as the solution to everything.

Maybe it's because they let me think in separate terms that are easier for me?

Sure, I think I understand. It would seem to be a way to organize your code around the state. I think I'll need to have a better grasp of it in order to compare it to general programming

> When I’ve looked at rule engines, I start seeing them as the solution to everything. They’re not 🙂 Don’t get me wrong rule engines are cool; and the right tool for more jobs than they’re used for — but they also have their problems.

I completely agree :)

One maintainability issue is classically horn clauses with strict implications aren’t great at representing exceptions to rules. For example to handle an exception you usually end up with every exception to X copied across every body involving X. Then if you have several exceptions they become hard to manage because of the duplication. Years ago I left university to join a spin out that had solved this problem; but we failed to find a market.

@U06HHF230 thanks! Can you point me to any resources that talk about this more? I don't quite understand what your saying, but that could be because I don't understand the fundamentals. So a rule could be something as simple as "A :- B" So an expectation would be, I'm not sure how to write this A and not C :- B. Where "not C" is the expectation?

There’s a lot of subtlety to the fundamentals, and I’m far from an expert so take what I say with caution as it’ll probably be wrong, or not universally true. Negation is really a whole other topic, because it can profoundly affect the type of logic you have, and introduce problems of its own. For example many logics only work monotonically, meaning that you can’t unconclude something later based on new evidence. i.e. all facts and their conclusions are always assumed to be true, and adding a new fact or rule can’t remove or disprove an existing conclusion. The common way to handle negation is known as Negation As Failure (NAF), and it’s how you’d do it in Prolog. However NAF essentially forces you to use the impure feature of Prolog ! (cut) which stops backtracking. To implement NAF you’d do something like:

neg(Goal) :- Goal, ! , fail.
neg(Goal) .

Essentially in Prolog there are two ways to reason about any program… procedurally, or declaratively and using ! blows away half of your reasoning and leaves you only with the procedural way… and having to fight ordering dependencies across rules.

Anyway NAF is normally supported directly in Prolog as \+ — but underneath it’s the same as the above.

Anyway this is a big digression, as it says nothing of the exceptions you asked about.

The classic example of the kinds of exceptions I’m talking about are expressing things like “All birds fly, except penguins”. In a monotonic logic you can’t do that.

As the exception would refute the rule “All birds fly” under strict implication… essentially the :- (if) in something like Prolog.

So you need a different type of logic - a non-monotonic, defeasible logic. Defeasible essentially means defeatable, i.e. the exception can override (defeat) the rule. So essentially we implemented := which was like :- but you’d read it as “it’s usually the case” instead of if. So you’d write :

flies(X) := bird(X) .
bird(tweety).

penguin(tweety).
notflies(X) :- penguin(X).

Anyway I didn’t have much at all to do with the underlying logic… that was all done by our CTO Chris Reed and based on the mathematical logic of Henry Prakken.

https://en.wikipedia.org/wiki/Negation_as_failure https://en.wikipedia.org/wiki/Non-monotonic_logic http://www.cs.uu.nl/groups/IS/archive/henry/DefArgJANCL97.pdf

A good explanation of NAF in Prolog: http://cs.union.edu/~striegnk/learn-prolog-now/html/node90.html

Thanks!! I'll get to reading this tomorrow!

Wow, thanks. I feel like this is helping me reframe things in a new light. There is a take interesting take away here that I'm right on the brink of seeing.

Your example didn't say much about needing to copy and paste. You can "refactor" around this example as long as you control the rule which inserts whether you fly or not.

Sorry… To take it further to explain that… you need to add another rule that uses the flies predicate… e.g. all things that fly are awesome…

awesome(X) :- flies(X).

awesome(X) :- \+ penguin(X), flies(X).

But penguins can't fly, so they aren't covered by that rule.

If you write flies as a long list of exceptions — which was the alternative above. Think of it like the difference between case and defmethod, it’s not open for extension. Also as I was trying to say negation has peculiar semantics due to the difference between not knowing something and knowing something is false. It also destroys the purely declarative nature of the rules — which is kinda why you’re using rules in the first place 🙂

Thanks mike, The more i read about a rules engine the more i feel its similar in nature. Can you clarify how you think its different? I have no real critique or goal in mind, just learning 🙂

At a deep enough level, its all events, logic and then changes. So everything is like everything else at a deep enough level. But at a more shallow level, there are no "rules" in re-frame, so, no, I don't see it. But there is data flow, some of it reactive, so I find that a better lens.

Thanks again, that makes sense to me.