I was toying-around with putting more binary definitions into the Dao.String module, and that required me to qualify the the import for Data.Binary.
The test program is still using an inordinate amount of memory, I've tried tweaking several parameters in the garbage collector, and changing the number of threads and the depth of the randomly generated objects, but nothing reduces memory usage. I'll need to investigate this.
The binary serialization coder/decoder is finally up-to-date with all the changes to the Dao scripting language definition I've made over the past half-year. I tweaked the definition of some of the nodes of the abstract syntax tree, and have started a rudimentary implementation of a new 'Dao.Object.ObjectExpr' called 'Dao.Object.MetaEvalExpr'.
I have started a rudimentary implementation of a new 'Dao.Object.ObjectExpr' called 'Dao.Object.MetaEvalExpr'.
I had completely forgotten to instantiate 'Dao.Object.TopLevelExpr' into the 'Dao.PPrint.PPrintable', that has been fixed now.
I decided 'Dao.Object.ToplevelDefine' is not necessary anymore. I will instead parse ordinary 'Dao.Object.ScriptExpr's at the top level and interpret them at what was called "SETUP" time. Since about 5 commits ago, the "SETUP" top-level node of the abstract syntax tree has been deleted, and "TAKEDOWN" has been replaced with "EXIT", and these nodes are now unified in the AST.
Incorporated the recent changes to the top-level nodes of the abstract syntax tree into the "Dao.Evaluator" module.
Top-level scripts will need some careful thought before they can be implemented properly.
I completely forgot to instantiate the 'Dao.Object.ArithOp1' and 'Dao.Object.ArithOp2' data types into the 'Data.Binary' class. I have fixed this now.
Re-defined the test program to test the parser for top-level expressions and the binary serialization coder/decoders, both are tested for every random object expression generated. Now, once again, it is simply a matter of fixing the bugs that turn up.