Question

I am rewriting an existing template solution with scripting support to run as an expression tree instead of interpreting the AST every execution and the logic has to work with existing scripts.

What I am trying to achieve right now is to create a solution to test for true.

Ex. strings that are null or empty is considered false as is 0 and any decimal value with an absolute value below 0.0001. “true” and “false” are what they say, case insensitive, and the string “null” is false.

The only input types valid are float, int, string and bool.

Any solution that can be worked into an expression tree to be compiled is valid and I already have an existing method to test an object but cannot find any good example to call an external method.

Every example either works on constant values or accepts no arguments.

Update

I am building the tree using “Expression.ABC” methods, but are having a problem funding a way to switch over the type of the result (string, int, float) of an expression tree.

Current syntax stores everything as strings and parses to int and float depending on the operation, returning a default value if it fails.

Its built to be failsafe and always succeed to generate the result, even when supplied with bad syntax in the template.

Update

Example (not 100 % accurate but to exemplify the current interpreter)

string Evaluate(Expr e) {
    switch(Expr.Type) {
        case "istrue":
            ExprValue value = Evaluate(Expr.Child);
            switch(value.Type) {
                case "String":
                    if(String.IsNullOrWhiteSpace(value.ToString()) || value.ToString().ToLower() == "false" || value.ToString().ToLower() == "null" || value.ToInt() == 0) return false;

                case "Int":
                    return value.ToInt() != 0;
                case "Float":
            }
    }
}

*Update * Changed title

Answer 1

The solution was to change the design.

My problem was that I was trying to do my cast at the wrong time, at runtime, but expression tree cannot handle that in a good way.

I redesigned the parser completely to have strongly typed methods and variables and explicit casts and that proved to be much easier to convert to an expression tree.