Re: Decision Tables

kwikius <andy@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:

On Jan 30, 12:11 am, Ben Bacarisse <ben.use...@xxxxxxxxx> wrote:
<snip>
I may be missing your point, but I *think* the OP wanted a way to
"store" (or at least represent) compound predicates which can the be
evaluated against an unknown data item.  I don't think your example
shows this.

Maybe :-)

It turns out the OP does not need as much as I thought!

I took your pseudocode:

"
complex_match[] = { match_contry, match_not, match_first_name,
match_or, NULL };
"
which is a static expression, and with the stack machine the language
is something like Forth ?

Just an array of function pointers. I missed out the bit where the
expression would be evaluated bu looping though the array calling the
functions.

and I figured that it wasnt very easy to read the expression syntax
and the solution seemed a prime candidate for C++ operator
overloading. Again the expression is statically evaluated.

It is hard to read but gives you a static way to store the "match
actions" rather than just write the match expression.

Once happy with the syntax, you could write a script which mirrors
the C++ syntax:

"first_name && (last_name || country)"

which is IMO easier to comprehend than:

"match_country match_not, match_first_name,
match_or"

Much easier to read by you can't store it in a data structure. That
is what I thought was needed. It is not needed, so I am just
explaining why I posted what I did.

--
Ben.
.