proposal for minor new feature

[John W. Eaton]

On  2-Mar-2010, Jaroslav Hajek wrote:

| for a while, Octave has had the "assert" function, to conveniently
| test for some conditions and error out on problems.
| However, there is no equivalent to NDEBUG in Octave - there is no way
| to switch assertions off for performance reasons.
| 
| Note that it does not suffice to shadow assert with an empty function;
| the point of NDEBUG is to also prevent evaluating the
| arguments to the call, which can be expensive. An optimization for
| that case would probably work neither, because at the
| point of function lookup arguments must already be evaluated.
| 
| What I propose is to implement a variable, say, "ignore_assertions",
| that would instruct the interpreter to ignore any calls to functions
| named "assert".
| This would necessarily include user-defined or local assert functions;
| as I said, at the point of function lookup it is already too late, so
| there is no nice way to distinguish which assert is called. I even
| think that it might be good to allow an user write his own assert
| (probably extend the library function) and still enjoy the feature.
| An even more general case would be to allow a set of names be defined
| as asserts, though I see little need for that.

There is the potential for confusion if you are using some code that
is not aware of the feature and provides an assert function (even a
subfunction or private function called assert?) and you set NDEBUG for
your session.

Would NDEBUG have to be set on the Octave command line or could it be
turned on/off during a session?  If so, would you have to clear all
functions when NDEBUG is set so that it affects all functions, not
just those that have not yet been compiled?  If you do that, then some
surprising things could happen with global or static variables.

If you write

  if (NDEBUG) assert (expensive_argument); endif

then the evaluation of expensive_argument and the assert call are both
skipped.  But you do have to evaluate the (global?) variable or
function NDEBUG.

Is that good enough?

| Finally, a yet far more general idea is to allow preprocessing in Octave.
| But admittedly, this is the only case I can think of where a
| preprocessor in Octave would do any good.

Using an #include statement could also provide a minor performance
improvement over script files, but now that script files are compiled,
I don't think this would be large, and could be confusing if an
included file changed but Octave didn't notice.  And checking
timestamps on #include files would likely negate any performance
increase, so I don't see the point of the added complexity for
#include.

I'd also prefer to avoid any macro expansion feature.  If you need
that, then I think the better solution is to preprocess your files
with m4, sed, awk, perl, or whatever.

jwe