Rules Engine or Event Collaboration

January 9, 2009

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.

Read the rest of this entry »


Event Driven Architecture Programming in Lisp Part 2

December 4, 2008

References for our discussion:

Requirements for our EDA:

  • Storage of events to be executed when events triggered.
  • Events.
  • Push/Pull Model.
  • Broadcast of events. One trigger can execute more than one handler.
    • Ex. When User Clicks Save Button, data is saved and the event is logged as executed.

Read the rest of this entry »

Event Driven Architecture Programming in Lisp Part 1

December 3, 2008
  • What is Event Driven Architecture Programming?
    • It is the ability to inform interested objects (consumer/subscriber/sink) of changes of state from other objects (producer/subscriber/source) with events.
  • Why use this architecture?
    • There are two reason to use this architecture. One is to loosely couple the interacting objects. The second is that it is best-suited for use in an asynchronous context.
  • What are the components required?
    • A table that stores event-handlers
    • An interface to register a trigger of events.
    • An interface to register notification of an event trigger.
    • An interface to trigger events.
  • How to represent events?
    • Closures

Read the rest of this entry »