Our challenge is to find a way to allow users to define and build complex expressions out of flexible building blocks of compiled code. Once a user defines an expression, it will be stored in two formats. One format would be fairly textual and descriptive, but still show parenthesis for grouping, and all operators with their standard symbols. A second format would be much more cryptic, and would be designed for rapid and efficient evaluation by an expression evaluator which we would have to write.

One approach that we will be exploring regarding how best to write an expression evaluator uses the following logic. If the expression evaluator has to parse out the logic embedded in the textual description each time it evaluates, it will be very inefficient. We would want to pass it a string of PseudoCode which would allow it to run much more efficiently, and also which might be suitable for compiling. Operators and operand types would all be assigned Tokens, which would be interspersed with codes and constants.

Lets take the following example.

Five days after a referral to a specialist for Physical Therapy we want to confirm that we have received a report from the therapist.

One approach would be to write a routine which scans the table that stores referral information to see if a response has been received and recorded, on all referrals more than five days old. This routine would work only for this one expression.

A second approach would be to create a routine that returns the date of a referral (for our example let's assume this is a field in a table that we have defined in a data dictionary with a unique identifier #001627), and another routine to indicate whether a report for the referral has been received ( another table field defined in a data dictionary under #001629). If the user wants to get a list of all referrals, he could create a new expression that relates these other two expressions in the following manner:

(Current Date - Referral Date) > 5 ) AND (NOT Referral Received )

The current date would be a system function, let's say in our list of system functions it is assigned the identifier # 00005. So using the tokens listed above we might be able to store something much more cryptic, but much faster for the computer to evaluate.

44	System Function
00005	Current Date system function
01	Subtraction Operator
45	Data Field Evaluator
001627	ID of data dictionary entry with type and full field information
11	> Operator
40	Numeric Constant
5	Value of Numeric Constant
21	AND Operator
20	NOT Operator
45	Data Field Evaluator
001629	ID of report received field.

By storing a sequence such as "44|00005|01|45|001627|11|40|5|21|20|45|001629|" we have something that an expression evaluator could decode and evaluate repetitively, at a much higher rate of speed then if it had to parse the textual string. This example is probably overly simplified. We would also have to deal with parsing parenthesis, and stack considerations. But through the use of tokens such as these we should be able to greatly increase the efficiency of processing events that users are able to define. Such rapid expression evaluation may be needed when we are receiving messages from live active applications which need rapid comparison with a large list of triggers in order to determine if the data that they contain constitutes a triggering event.

In situations where we will be scanning data in SQL databases in a passive or background mode, a more viable and efficient option may be to create an embedded SQL expression which the system can use to find all matching records, or provide help lists and hints which will allow the user to see and edit an SQL expression directly. Another option that we will be exploring is the creation of embedded SQL statements based on variables and constants that a user selects.