Logic

At this point we’ve developed a complete, though very simple, interpreter and runtime environment.  To some degree, this interpreter is all we need.  It can express any function, it can easily be extended, it has a simple parser, and it has a working garbage collector.  What more could we ask for?  Life is good.

Life is good, that is, until we ask somebody else to use it.  Their first response is probably an annoyance at the syntax — it’s a little surprising to have to write (+ 1 1) after grade school has burned 1 + 1 into our minds — and, truth be told, the S-Expression syntax isn’t the most natural or compact for every problem.

Luckily we can, with a little work, entirely eliminate this complaint by creating a parser generator — a function that takes as input a grammar (a formal description of a language), and produces as output a parser for that language.

Read the rest of this entry »

CEP engines try to keep state-management out of the developers’ hands (or, if you prefer, out of your way), letting you concentrate on just the events. Inevitably, though, we end up needing just a little more state than we have in the current event stream; or we have an event that’s needed by several monitors (e.g., benchmark prices); or the event data’s needed in several monitors, but doesn’t actually trigger any action.

Enter the cache-monitor: a common Apama pattern we’ve used in our projects. It’s a simple pattern, but I’m posting it to illustrate Apama’s programming model which seems to be not common knowledge. What throws people for a loop at first is that in order to retrieve a value from a cache-monitor, we mimic a function call from typical procedural languages by routing a Request-event to that monitor, and listening for the matching Reply-event routed back to us by the cache. To see what I mean, consider the 3 snippets below. Read the rest of this entry »

Nothing comes from nothing
Nothing ever could.
So, somewhere in my youth or childhood
I must have done something good.

Read the rest of this entry »