Bug fix: when evaluating 'Dao.Object.Equation' expressions in the 'evalObjectExprWithLoc' function, some 'Dao.Object.UpdateOp' operators require special consideration before being evaluated, for example the 'Dao.Object.DOT' and 'Dao.Object.POINT' operators which require one or both of their operands to NOT be de-referenced before being evaluated. I hadn't thought of this before but the 'Dao.Object.AND' and 'Dao.Object.OR' operators also require special consideration in order for the @&&@ and @||@ operators to behave as they do in the C family of programming languages. With these operators, the right-hand operand must NOT be evaluated or de-referenced if the value produced by the left-hand operand can decide whether the expression evaluates to true or false all by itself. I thought perhaps Haskell's laziness would just do the right thing, but the 'Dao.Object.Exec' monad is lifted into the @IO@ monad, so laziness was not possible -- as I had written the code, both the right and left hand side of an operator in an 'Dao.Object.Equation' expression were evaluated before being passed as parameters to the operator function, and therefore the IO monad had to resolve these values before proceeding, thus both sides of the expression are always evaluated first. I had to re-write that part of the code to treat 'Dao.Object.AND' and 'Dao.Object.OR' as a special case.
I just realized that the thing I was testing doesn't work because Dao executes all matches in parallel. I had completely forgotten one of the most important features of my algorithm!