Includes words for assertions as defined in gforth:
assert0(, assert1(, assert2(, assert3(, start a new assertion. Levels 0 and 1 are enabled by default, higher levels require the assert level to be increased.
For convenience, assert( is an alias for assert1(
assert-level is a host variable that indicates the current assertion level. Set to 1 by default, and can be changed to 0, 1, 2, 3, with the word assert-level! (non-standard, but needing to switch to [host] is a bit awkward otherwise).
Assertions that are not active (i.e. with a level higher than the assert-level at compile time) behave like ( and are not compiled to the ROM at all.
Example usage:
require assert.fs
2 assert-level!
: main
assert( depth 0= )
\ do other things here...
assert2( big-computation 42 = )
\ some more stuff...
bye ;
Error message
I initially defined the behaviour of the "error handler" to simply show a message assertion failed and run bye to stop execution directly, but this would make it hard to know which assertion to check (the target device is not able to show a stack trace on THROW).
The current version shows the possibility to include a file.fs:42 in the error message, which is great for debugging, but comes at the cost of using more ROM to store the filenames and linenumbers in.
Of course, you can always disable assertions you don't need anymore, but I'm not sure what the better tradeoff is yet.
Includes words for assertions as defined in gforth:
assert0(,assert1(,assert2(,assert3(, start a new assertion. Levels0and1are enabled by default, higher levels require the assert level to be increased.assert(is an alias forassert1(assert-levelis a host variable that indicates the current assertion level. Set to1by default, and can be changed to0,1,2,3, with the wordassert-level!(non-standard, but needing to switch to[host]is a bit awkward otherwise).assert-levelat compile time) behave like(and are not compiled to the ROM at all.Example usage:
Error message I initially defined the behaviour of the "error handler" to simply show a message
assertion failedand runbyeto stop execution directly, but this would make it hard to know which assertion to check (the target device is not able to show a stack trace on THROW).The current version shows the possibility to include a
file.fs:42in the error message, which is great for debugging, but comes at the cost of using more ROM to store the filenames and linenumbers in.Of course, you can always disable assertions you don't need anymore, but I'm not sure what the better tradeoff is yet.
Todo