Discovered a function specific to object expressions in the "Dao.Random" module, moved it to the "Dao.Object.Random" module. Also, added a few more words to the 'Dao.Random.randomWords' function.
I have been trying to align the random object expression generator with the parser so the 'Dao.Random.HasRandGen' instance of 'Dao.Object.AST.AST_Object' randomly creates 'Dao.Object.AST.AST_Object' data structures identical to how they are parsed from the pretty-printed expressions of those data structures. So far, I have made improvements, but have discovered other problems. Also, I discovered a function specific to object expressions in the "Dao.Random" module, and have moved it to the "Dao.Object.Random" module.
I had to update the pretty-printer a bit to make it cooperate a bit better with the random object generator. In the random object generator, I try to generate the most diverse range of object expressions as I possibly can. In this case, there was a chance for me to include 'Dao.Object.ORatio' and 'Dao.Object.OComplex' object values in the list of primitive expressions that can be generated randomly. Expressions like "1024R" or "1.024e-4i" are primitive expressions, but "(1/14R)" and "(0+1.024e-4i)" are not primitive because each will be parsed to an arithmetic expression within a parenthetical expression. The pretty printer for 'Dao.Object.ORatio' and 'Dao.Object.OComplex' will print either the primitive or non-primitive form depending on the value. In order to get at least some 'Dao.Object.ORatio' and 'Dao.Object.OComplex' values in the set of randomly generated values, I modified the pretty-printer so it outputs the primitive form when it is possible to do so. In the case of 'Dao.Object.ORatio', the primitive form is printed when the denominator is one, in the case of 'Dao.Object.OComplex', the primitive form is printed when the real component is zero.
Modified the parser for the 'Dao.Object.Parser.reference' function, which parses the function headers for the 'Dao.Object.AST.AST_FuncCall' and 'Dao.Object.AST.AST_ArraySub' nodes of the abstract syntax tree. Now function headers can no longer be arbitrary 'Dao.Object.AST.AST_Object' expressions, they must be another reference expression. Not only does this make more sense, but it makes it easier to parse expressions generated by the "Dao.Object.Random" module in an unambiguous way. It also results in fewer backtracks during parsing which has improved the parser performance.  Along with the changes made to the "Dao.Object.Random" module, the program is showing approximately a 50% increase in the number of tests completed per second. This is a significant optimization.
Also, removed "this" and "super" from the list of reserved keywords, they can be treated as ordinary references.
Added another API function to the 'Dao.String.UStrType' class called 'Dao.UStr.maybeFromUStr', which allows you to evaluate to 'Prelude.Nothing' if the parameter string does not map to any data constructor for the polymorphic data type. This allows conversion failures to be detected in pure functions, rather than using 'Prelude.error' and waiting for the exception to be caught in the IO monad.
Added a new prefix operator: the plus sign. Prefixing an arithmetic expression with a minus sign is valid syntax, so I think it would be confusing to programmers if you were not allowed to write expressions prefixed with a plus sign.
Also, added another API function to the 'Dao.String.UStrType' class called 'Dao.UStr.maybeFromUStr', which allows you to evaluate to 'Prelude.Nothing' if the parameter string does not map to any data constructor for the polymorphic data type. This allows conversion failures to be detected in pure functions, rather than using 'Prelude.error' and waiting for the exception to be caught in the IO monad.
Changed the name of the 'Dao.Object.ArithOp1' data type back to 'Dao.Object.PrefixOp', and the name of the 'Dao.Object.ArithOp2' data type back to 'Dao.Object.InfixOp'. I believe the reason I used 'ArithOp1' and 'ArithOp2' was because I was often confusing the words "suffix" and "infix". But I think it is better to call a data type what it is, so I will just have to be careful with the difference between "suffix" and "infix" in the future. Hopefully it will not cause me too much grief.
I had just modified how 'Dao.Object.InfixOp's and 'Dao.Object.PrefixOp's are converted from strings.  They used to be converted by 'Prelude.Read', now they are converted by 'Dao.String.maybeFromUStr'.  While I had done this, I had also reverted the instantiation of 'Prelude.Show' for these data types to the derived instantiation, but I forgot to update the pretty printer to use 'Dao.String.uchars' instead of 'Prelude.show'.
Updated the pretty printer to place a space between the end of the "try" statement block and the "catch" statement if the statements are written on the same line.
The POINT (->) and DOT (.) operators, and every single assignment/update operator, are all right-associative, and are correctly parsed as right-associative. However the random object generator was generating 'Dao.Object.AST.AST_Equation' and 'Dao.Object.AST.AST_Assign' 'Dao.Object.AST.AST_Object' expressions that were left-associative. This has been fixed.
Bug fix: the parser for top-level nodes in the abstract syntax tree were parsing the string literal parameters to the "import" and "require" statements incorrectly.
Bug fix: container objects like lists and dictionaries were still generating arbitrary object values instead of object expressions that must be identical to the kind of object expression data structures emitted by the parser. I corrected this, and also added a new random object generator for 'Dao.Object.AST.AST_Data' nodes in the abstract syntax tree.
Bug fix: the random data expression generator was generating lots of individual chunks of random data, instead of one long chunk. This should cause an error because each chunk will often end in an equals sign, and this signifies the end of data. Seeing more data after an equals sign is an error.  The random object generator has been corrected to prevent this from happening.