
This patch adds a simple assertion mechanism to the Inform 6.30 compiler.
Assertions let you embed runtime error checks into Inform programs, and
receive notifications if any of the checks fail.  Inform assertions work
much like assertions in other languages.

Once the compiler has been patched, you can add assertions to your Inform
code using the following syntax:

    assert <any boolean expression>;

for example

    ...
    money = count_coins();
    assert money >= 0;
    ...

Add the -A option to the Inform compiler command line to enable assertions. 
Then, if the condition is ever false when the program executes, Inform
prints an error message indicating which assertion failed, for example

    --- Assertion failed, at line 36024 in file '32k.inf'.

Unlike 'C' assertions, Inform will not automatically abort the program when
an assertion fails.

If the -A option is not given to the Inform compiler, the compiler checks
the assertion for validity and syntax, but does not compile it into the
program.  This means that assertions add nothing to a game's run time or
compiled game file size when they are turned off.  It also means that the
boolean expression you put into an assertion should not have side effects.

You can define your own assertion failure handler, to replace the default
one supplied by the compiler that prints the error message above.  To do
this, define a function __AssertFail, something like

    #ifdef ASSERT_MODE;
    [ __AssertFail file line;
        print "Assertion failed: ", (string) file, ":", line, "^";
        quit;
    ];
    #endif;

A couple of notes about this definition.  Firstly, it's surrounded by
#ifdef's to avoid compiling it in to builds without assertions; this also
stops the Inform compiler flagging it as an unused function definition
(assuming it's not in a system file).  The compiler automatically defines
ASSERT_MODE if handed the -A flag.

Secondly, for large input files and Z-machine builds, a 16bit line argument
may not be wide enough to hold the line number.  So for these cases, line is
set to modulo 10,000, and a third argument is passed to hold the line number
divided by 10,000.  Ugly, but it affects only Z-machine builds where the
line count in an input file exceeds 10,000, so for the most part, it should
not pose a problem.  Glulx uses a 32bit word size, and so doesn't suffer
from the same limitation.

If you notice any problems with this patch, please drop me a line at
simon_baldwin@yahoo.com.

