Broke off three more constructors from the 'Dao.Evaluator.AST_Object' node into their own node: 'Dao.Evaluator.AST_RuleFunc' now has constructors for 'Dao.Evaluator.AST_Func', 'Dao.Evaluator.AST_Rule', and 'Dao.Evaluator.AST_Lambda'. The reasoning for doing this was to allow the 'Dao.Evaluator.AST_Script' node parse rules, functions, and lambda expressions in the top level without requiring a semicolon after then. The 'Dao.Evaluator.AST_RuleExpr' constructor contains an 'Dao.Evaluator.AST_RuleFunc' typed node with not semicolon. However as container objects, it is also possible to use these 'Dao.Evaluator.AST_RuleFunc' type expressions as object expressions, so the 'Dao.Evaluator.AST_Object' data type also has a constructor, 'Dao.Evaluator.AST_ObjRuleFunc', for storing 'Dao.Evaluator.AST_RuleFunc' typed nodes which must be followed by a semi-colon.
Fixed one more bug in the parser which I had created in this most recent change to the abstract syntax tree: the 'Dao.Evaluator.AST_ObjRuleFunc' and 'Dao.Evaluator.AST_RuleFunc' nodes are similar except the former requires a semicolon after it. I needed to make the parser check for a semicolon and if it existed return the former, or else continue parsing an 'Dao.Evaluator.AST_Assign' expression, then get a semicolon, then return the former, or else return the later alone without a semicolon.
Updated the evaluator so the semantics of the Dao scripting language makes a bit more sense given the recent changes to the abstract syntax tree: lambda expressions, function expressions, and rule expressions are now their own node which can be expressed within an arithmetic expression, or can stand on their own in a sequence of directives. Either way, when such an expression is evaluated, it check if it has been evaluated within a function call or at the top level. If within a function call, functions and rules are added to the static local variables context, otherwise they are placed in the normal top-level context.
The test program is experience space leaks. To begin troubleshooting this problem I have modified the random object generator class and the existing random object generators to provide slightly more detailed statistical information about the objects generated. In particular, the "weight" of the object, or you could call it the size of the object as measured by counting the number of random nodes produced in the abstract syntax tree. I also have been trying to tweak how to measure recursion in recursive objects to prevent objects sizes from spinning out of control.
Modified the 'Dao.Random.HasRandGen' class so that now random generators can expose the list (actually an array type called 'Dao.Random.RandChoice') of randomly selected constructors as the 'Dao.Random.randChoice' function. This way other instantiations of 'Dao.Random.HasRandGen' can make use of arrays of other random generators by composing other 'Dao.Random.RandChoice' arrays.
Overhauled the 'Dao.Glob' module with the knowledge and experience that I have gained in the approximately two years experience of coding with the Haskell language that I have gained since the last time I modified this file. New 'Dao.Glob.Glob' expressions store 'Dao.Glob.Widlcard' matches into named variables now, rather than into numbered variable references. This means you no longer use "$1", "$2" and so on to retrieve matched pattern values in Dao scripts.
Pattern matching now binds 'Dao.Glob.Wildcard's to local variables given by variable names expressed
in the 'Dao.Glob.Glob' string. This is different from before where values that matched
'Dao.Glob.Wildcard's were placed into an array in the order in which they matched the input string.
This also means ordinary variable names in the script action associated with a 'Dao.Glob.Glob'
pattern now refer to the values matched by the 'Dao.Glob.Glob' pattern 'Dao.Glob.Wildcard's. Again,
this is different from before where values that matched 'Dao.Glob.Wildcard's could be retrieved by a
dollar-sign and then the number of the place in which the 'Dao.Glob.Wildcard' matched, for example:
    a = $1; b = $2;
and so on.

After making so many changes to the abstract syntax tree I realized that creating an additional node
in the syntax tree to handle these dollar-sign references was pointless. So I overhauled the
"Dao.Glob" module. I changed how 'Dao.Glob.Glob' expressions are parsed so 'Dao.Glob.Wildcard's now
must be associated with a variable name in the pattern text. I overhauled the matching algorithm to
make use of these variable names while matching.

I also now have a new feature: variable back-references. Variable names may occur twice in the same
'Dao.Glob.Glob' expression, every occurrence of a variable name after the first occurrence does not
behave as a 'Dao.Glob.Wildcard', rather it will expect to match the string tokens that were matched
by the first match of the 'Dao.Glob.Wildcard' bound to that variable name.

Finally, 'Dao.Glob.Glob' expressions have been made polymorphic over the 'Dao.Glob.Single'
constructor to allow for a wider range of variables types to be used for pattern matching, not just
'Dao.String.UStr's. I have also created a 'Dao.Glob.FuzzyStr' newtype wrapper around
'Dao.String.UStr' that matches strings using a fuzzy instantiation of 'Prelude.Eq'.