Implied deftemplates considered harmful
CLIPS is an extremely flexible and adaptive programming environment. Unfortunately, that's not always for the best.
Implied deftemplates (see chapter 3.4 in CLIPS Basic Programming Guide) can be a nuisance when debugging. It makes a difficult task even more difficult because certain, *trivial*, errors (more specifically, spelling errors) can go undetected. It's a bit similar to weak typing, though usually not as bad.
I've learned (the hard way) to stay clear from ordered facts and implied deftemplates but if you still do use them and your application isn't really behaving as you expect. Try a (list-deftemplates) as your first debugging effort. You may well be surprised.
Labels:
CLIPS,
Programming
7 kommentarer:
Ordered facts are useful for prototyping and doing quick demos. It is very easy to abuse ordered facts though. For a real application, ordered facts shouldn't be used, since they are slower than un-ordered facts.
ART supported a schema system that provided the same functionality as deftemplate named slots but also supported inheritance. The practical drawback to using it was that it generated one fact for each slot of an object (which was eventually reimplemented), so it was fairly common to use ordered facts to avoid the "clutter" (at least when the facts had a relatively small number of attributes and inheritance was not needed). Ordered fact patterns were not only prone to spelling errors but positional errors because patterns such as (vehicle ? ? ? ?make ?model $?) were the standard mechanism for retrieving attribute values.
Deftemplates were added to CLIPS to provide something in between ordered facts and schema in functionality but without the overhead of the schema system. They were based on the OPS5 literalize statement and originally had the same OPS5 limitation that you could only have one multifield attribute per template.
Hi Peter,
For a real application, ordered facts shouldn't be used, since they are slower than un-ordered facts.
True. And, don't forget, they're more difficult to maintain, read and understand.
Hi Gary,
and thanks for the history lesson. It's always interesting to learn more about the context in which decisions were made.
The practical drawback to using it was that it generated one fact for each slot of an object ...
Is that similar to (or exactly like) Object-Attribute-Value (OAV) triplets?
Ordered fact patterns were not only prone to spelling errors but positional errors ...
Good point. Positional errors are even worse. Spelling errors are at least easy to detect. But figuring out that you've added one too many (or too few) '?' in a pattern could take a while I imagine.
OAV might not be as common of an abbreviation as I thought. EAV is probably better (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model).
yeah, using ordered facts leads to a complete maintenance nightmare for a real project with lots of rules.
Yes, ART schema were represented as a collection of OAV/EAV facts, but the original implementation as exposed to the user was not ideal.
Skicka en kommentar