Major bug fix: this fix was actually completed a few commits before this
one, but I thought as long as I was updating the TODO file, I would go
into more detail about how I fixed t.

In summary, two corrections have been made: (1) resolving undefined
references using 'Dao.Interpreter.referenceLookup' is discernible
resolving defined references to function calls that backtrack by
throwing void. (2) throwing errors is much cleaner and error reporting
has been improved.

This problem has plagued me for about two weeks now, but finally it is
fixed. Almost all of the instances of the 'Dao.Interpreter.ObjectLens'
class had to be partially re-written to better respond to situations
where references were undefined. Before hand, undefined variables would
result in inconsistent behavior in that one of two things could have
happened: (1) either an error could be thrown, or (2) the function would
backtrack by evaluating to 'Control.Monad.mzero'.

In the Dao language, function calls are first-class reference values,
for example the Dao language expression "$f(0)" is a reference value
that will execute a function call "f(0)" when de-referenced.

Now, if an undefined reference results in backtracking, this creates an
ambiguous situation: what to do when the function call reference "f(x)"
is resolved where "x" is undefined and "f" backtracks regardless of the
value of "x". For example in the expression:

    global N=0;
	function f(x) { if(global N == 0) { throw; } return x+1; }

Here if "N" is 0 then it will not matter whether or not "x" is
undefined, the function "f" will backtrack. However if "N" is set to
a non-zero value, then the reference "f(x)" will fail because "x" is
undefined. In both situations the function backtracks.

However, the 'Dao.Interpreter.referenceLookup" function was defined to
throw an "undefined reference" error if any function lookup backtracked,
even if the function backtracked because of a "throw;" statement rather
than a legitimate undefined reference. And because of the ambiguity
between how backtracking was used, there was no way to tell the
difference between an undefined reference and the program backtracking
for some other reason unrelated to references being defined or not. In
the above example, was an undefined reference error occurring because
"N" was set to zero, or because "x" was undefined? There was no way to
know.

To solve this problem, I re-defined the 'Dao.Interpreter.ObjectFocus'
monad to treat backtracking caused by function calls in the lifted
'Dao.Interpreter.Exec' monad as a separate kind of error condition data
type 'Dao.Interpreter.ObjFocusError' that wraps the
'Dao.Interpreter.ExecControl' data type, but also contains a separate
constructor called 'Dao.Interpreter.InnerExecBacktrack' which is thrown
when a lifted 'Dao.Interpreter.Exec' monad backtracks. Then, at the
boundary between the 'Dao.Interpreter.ObjectFocus' and
'Dao.Interpreter.Exec' monads, in the 'Dao.Interpreter.runObjectFocus'
function, if the function resolved to the error condition
'Dao.Interpreter.InnerExecBacktrack', 'Dao.Interpreter.runObjectFocus'
would evaluate to the backtracking value 'Control.Monad.mzero'. If
however the 'Dao.Interpreter.ObjectFocus' backtracked, the
'Dao.Interpreter.runObjectFocus' function will throw an 'UndefinedRef'
error.

I have also eliminated the 'Dao.Interpreter.lookupIndex' function from
the 'Dao.Interpreter.ObjectLens' class, and reference lookups are now a
special case of updates. There is a new boolean value in the
'Dao.Interpreter.ObjectFocus' monadic state that indicates when a lookup
is intended, and this boolean is used to prune the search tree when
performing lookups, as updates may be intended to actually write a
previously non-existent value into a name space rather than backtrack
when it does not exist.

This change in behavior required some fine tuning, but it all works now,
and is a much more elegant solution to the ugly hacks I had written to
solve the problem before. Furthermore there is less code as lookups are
now a special case of updates and not their own separate functions.

At first I had intended for this fix to treat undefined references as a
special case of backtracking with a function similar to
'Control.Monad.mplus' especially defined to respond to undefined
references in a way that would backtrack and try to resolve the
reference in alternate namespaces. However this turned out to be not
nearly as nice of a solution to the problem that I described above and I
abandoned this attempted solution. Fortunately, this attempted solution
did force me to improve the 'Dao.Interface.ExecControl' data type and
the whole mechanism for error throwing and error reporting. So this
merge includes these modifications as well.
Bug fix: glob patterns that ended with a single-token variable
followed by a multi-token variable were not matching patterns
correctly. For example the pattern:
	"$A?$B"
The "$A?" variable (with a question mark, which indicates a
single-token match) followed by the "$B" variable (with no question
mark, which indicates a multi-token variable) should match any string
of tokens with one token being assigned to A and zero or more tokens
being assigned to B.

The bug was that if no tokens were assigned to B, i.e. B was to be an
empty list of tokens, the pattern would fail to match. This has been
fixed. Now B will be assigned an empty list of tokens if the above
example pattern were to be matched to a string of one tokens.

While I was at it, I also updated some of the comments, and renamed a
few of the type variables to be less confusing. Because as I was
trying to solve this bug I became confused by my variable names, I
thought I would name them more appropriately.
Improved the "example/numbers.dao" program. This one is more efficient
and has more features, and works more correctly. In writing this
program I have discovered more bugs which I will need to fix later.
Added a new built-in function "reverse()" for reversing the items in a
list objects.