I said I would not do this, but I am going to try and move all of the
data types related to the Abstract Syntax Tree (AST) into their own
module "Dao.Interpreter.AST", and have this module imported by the
"Dao.Interpreter" module. I will do this removing any reference to the
'Dao.Interpreter.Object' data type and replacing it with a polymorphic
type.
Updated the Makefile so the Haskell source files containing the "main"
functions would not be included in the CHANGED_FILES variable. Since
there are multiple files with a "main" function defined, and if more
than one of these files had been modified since the last build time,
"ghc --make" would get confused seeing more than one "main" function
defined within the set of files specified on the the command line.

Also, forgot to modify the edit-files.list in accordance with the change
made in the the last commit.
Moved the 'Dao.Interpreter.AST_ObjRuleFunc' constructor from the
'Dao.Interpreter.AST_Object' data type to the
'Dao.Interpreter.AST_ObjTest' data type. This means lambda expressions
like "function(){}" or "rule(){}" cannot be used in an arithmetic or
assignment expression unless it is contained in parentheses. This is a
deviation from the JavaScript syntax, but it is important because it
resolves an ambiguity in the grammar of the Dao programming language.
The ambiguity is explained hence:

The following two lines of code are correct grammar:

	// (example 1)
	function() {}
	function() {}

Each function is parsed as an AST_Script type, constructed with the
AST_RuleFunc (AST_Lambda ...) constructor.

	// (example 2)
	function () {}
	function () - f(x);

The first function is parsed as an 'AST_RuleFunc' data type, the second
is parsed and stored as an 'AST_RuleFunc' in the constructor:

	AST_EvalObject (AST_Eval (AST_ObjArith (AST_Object (AST_Object ...))))

the semantics of which is function object being subtracted by the value
of f(x). However, while these three lines of code:

	// (example 3)
	function () {}
	function () {}
	-f(x);

are probably intended by the programmer to first create an anonymous
function "function () {}", then evaluate f(x) and negate it's result,
unfortunately this grammar is identical to the code in example 2 because
newlines make no difference to the grammar.

In JavaScript, this ambiguity is resolved by the fact that semicolons at
the end of lines are optional (and thus newlines are part of the
grammar). I do not ever intend to make the Dao programming language
allow for optional semicolons, I feel this is an unclean way to write
code.

So in order to resolve this ambiguity, lambda expressions now have the
same precedence as the (? :) conditional evaluation expression. I have
tested this modification to the grammar, and it does not disrupt any of
the existing Dao programs I have written so far, and the test suit has
executed over 250000 randomly generated grammatically correct
expressions and this there have been no ambiguities so far.

So I am committing this change.