Models of Computation
Some examples of models of computation include General Recursive Functions, Turing Machines, Lambda Calculus, Finite State Machines, and Production Systems. These are only some models of computation.
Martin Fowler has a pretty good post on rules engines (production system). “… providing an alternative computational model.”
Wikipedia’s definition is “A model of computation is the definition of the set of allowable operations used in computation and their respective costs.” I myself like the definition provided by “The Computational Beauty of Nature” [p27]. “… a model of computation describes how to build recipes or, if you like , a recipe for recipes.”
Both definitions seem to define two different things. The first definition describes programming languages. The second describes meta programming. These two definitions are not mutually exclusive. All programming languages have some form of meta programming. Just some languages have more powerful meta programming facilities.
In Common Lisp the most common way for the usage of meta programming is through the use of defmacro. Bill Clementson’s Blog post covers Joswig’s use of an embedded DSL in Lisp. Guess what allows him to make such a compact DSL? defmacro of course. Another nice Joswig post on comp.lang.lisp goes through an iterative cycle of design using defmacro.
Benefits and Liabilities of Using The Model
In Fowler’s post he spends about half of it talking about the liabilities of a RulesEngine.The liabilities that he describes are not so dissimilar to the liabilities associated to using Event Collaboration. The benefits are also similar. At this time I believe it is due to the nature of rules engine and event collaboration are based on graphs. Research on RETE to find the similarites, I think is in order.
+Weak Coupling and High Cohesion. Allows rules and events to evolve without making changes all over system. Does not need to have dependencies between rules or events in order to execute.
+Asynchronous Communications. Any rule or event can be executed at any time or in any order.
-No Implicit Dependencies. It is hard to debug due to complex interactions with loose coupling.
-Duplicated Data and Code. Rules and events can have the proerty of subsumption. In other words more specific rules or events can be taken over by more general rules or events.
Comments in this section is welcome
1. Limit set of rules and events.
2. Reduce cyclic triggering of rules and events
5. Utilization of system as soon as possible.
If you liked this you might like this:
Please leave any comments, they will be appreciated.