Modified the 'Dao.NewParser.PTable' API to make it more general. Before the 'Dao.NewParser.PTable' was required to store 'Parser' values, but now it can store any function that takes a 'Dao.NewParser.TokenAt' value and evaluates to a polymorphic type. This makes 'Dao.NewParser.PTable' much more flexible, allowing programmers to store functions of an arbitrary number of parameters into the 'Dao.NewParser.PTable'. This flexibility allows me to write fewer parser tables accomplish more. Unfortunately, making it more general also means making the types of these functions more complicated. I have added the 'Dao.NewParser.joinEvalPTable' and similar functions to try and make things easier. The idea is, a programmer may store functions from a 'Dao.NewParser.TokenAt' value to any polymorphic type into an array but the polymorphic type should almost always be simply a 'Dao.NewParser.Parser'.  The 'Dao.NewParser.bindPTable' function has only had it's type changed, but like before, will only operate on tables that store 'Dao.NewParser.Parser' elements.
Incorporated the recent changes to the "Dao.NewParser" module. Also did a fairly major re-arranging of the 'Dao.Object.AST_Object' parsers, which has fixed a few more bugs and also made the code a bit more elegant.
I have not updated this file for a while. I am starting to shift over to the new parser and am doing tests more and more often. But the dependencies for the test programs have not been updated to include the new parsers yet. This has been rectified, and now re-making tests is much easier.
Changed the syntax a bit, in two places:
(1) Container expressions (e.g. "struct", "list", "dict", "function", etc.) can now be juxtaposed by a list of parameters in parentheses or a list of indices in square brackets.
(2) Curly braces are now required after a "struct" statement to prevent confusion as to where the "struct" statement ends.
Modified the random object generator to generate 'Dao.Object.AST.AST_Object' expressions that are parsable by the recent modifications to parser. It is a design flaw that the abstract syntax tree can construct expression that cannot be constructed by the parser, but I will have to correct this flaw later. I have noted this in the TODO document.
Created a random syntax generator for generating possibly void object expressions for use in expressions where voids are allowed.
Had to update the pretty printer for the 'Dao.Object.T_tree' type to make it output syntactically correct code according to the recent changes to the "Dao.Object.NewParser" module.
I had forgot that Base-64 data expressions can have "=" characters at the end of them. I updated the lexer so it accepts an unlimited number of "=" characters in a "data" statement. I would like to have the parser check if equals signs occur in the middle of the input and throw a compile-time error if they do. For now, I don't think there is any need to throw an error in the lexical analysis phase.