Defined a new function 'Dao.Stack.stackUpdateTopM'. The problem with the function 'Dao.Stack.stackUpdateM' is that when you want to bind a variable that has not been bound before, it will scan every level of the stack looking for a bound variable name, and update it if it exists.  That means if you push a new context onto the stack and bind a variable name to a variable name bound in a higher level, the already-bound variable will be re-bound. When the stack is popped, that modification remains because it occurred in a higher level of the stack. This is not how programmers expect name binding to work when binding a previously unbound variable name using the equal "=" operator. It should only work this way when looking-up a value already bound to a variable name.

The 'Dao.Stack.stackUpdateTopM' function works as expected: When assigning values to unbound variable names will always occur in the top level of the stack, even if the name is bound at a lower level. This behavior is more similar to how C-like languages work, where variables names bound within any block of code enclosed in curly-brackets will mask identical variable names in it's containing block of code. The 'Dao.Stack.stackUpdateM' function can still be used when updating a value for an already-bound variable name and not binding an unbound variable name.
Several small bug fixes in the "Dao.Evaluator" module have been made.

On line 1011 the function 'Dao.Evaluator.taskLoop', which evaluates a 'Dao.Evaluator.Task' in a parallel thread, was evaluating the task IO function twice. This was because I had made a correction without deleting the prior code, so both the prior code and corrected code were being evaluated.  This has been fixed now.

On line 1086 I had defined the 'Dao.Evaluator.qualRefUpdate' function to evaluate to 'Control.Monad.mzero' if 'Dao.Evaluator._objectUpdate' returned a 'Data.Maybe.Nothing' value. This was causing a problem for any function that defined variables that had not been defined before, as any new variable defined would backtrack in the 'Dao.Evaluator.Exec' monad and the variable would go undefined. This has been corrected, and now unbound variables names be bounds to values even when they have never been defined before, conforming to my vision of the Dao programming language design.

I had hand-written the 'Dao.Evaluator.InfixOp', 'Dao.Evaluator.UpdateOp', 'Dao.Evaluator.RefPfxOp', and 'Dao.Evaluator.ArithPfxOp' instantiations into the 'Prelude.Bounded' class. This is error prone and unnecessary busy work, and a mistake in 'Dao.Evaluator.InfixOp' was causing an array indexing error. Now that I am using the -XGeneralizedNewtypeDeriving build flag for GHC, the instances for 'Prelude.Bounded' are derived, and no more array indexing errors occur.

Finally, the instance of 'Dao.Stack.Stack' into the 'Dao.Evaluator.Store' class makes use of the newly defined 'Dao.Stack.stackUpdateTopM' function when assigning values to unbound variable names will always occur in the top level of the stack, even if the name is bound at a lower level. This behavior is more similar to how C-like languages work, where variables names bound within any block of code enclosed in curly-brackets will mask identical variable names in it's containing block of code.
Corrected two bugs uncovered by the test routine.

On line 708, in the parser for the logical not prefix operator "!", the order of parsing whitespace and the expression following the "import" or "require" keyword had been reversed so any expression where whitespace occurred between the "!" operator and the operand was backtracking, resulting in a parser error.

On line 827, there is a parser that parses 'Dao.Evaluator.AST_Script' expressions that must inspect object expressions to determine whether or not they must be followed by a semicolon. Function and rule expressions may be followed by a semicolon. If they are followed by a semicolon they form 'Dao.Evaluator.AST_Eval' expressions rather than 'AST_RuleFunc' expressions -- this is how the pretty-printer differentiates between whether or not a semicolon was used. However the 'Dao.Evaluator.AST_Script' parser that inspected whether or not a semicolon was used formed a parser that was masking the 'Dao.Evaluator.AST_Arith' expressions parser. Therefore if an 'Dao.Evaluator.AST_Arith' expression used a function or rule expression on the left-hand side of an infix operator the expression would be parsed as a 'Dao.Evaluator.AST_RuleFunc' expression, and then fail on the infix operator as the 'Dao.Evaluator.AST_RuleFunc' parser returned control to the 'Dao.Evaluator.AST_Script' expression parser which expecting another 'Dao.Evaluator.AST_Script' expression rather than an infix operator. This has now been fixed.