Re: proposal for minor new feature

[Jaroslav Hajek]

On Tue, Mar 2, 2010 at 5:05 PM, John W. Eaton <address@hidden> wrote:
> 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.
>

Yes. The answer is: in that case, don't use the feature. Of course it
would be off by default.

> Would NDEBUG have to be set on the Octave command line or could it be
> turned on/off during a session?

I was thinking about a pseudo-variable (like ignore_function_time_stamp etc).

> 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.
>

Good point. I suppose that toggling the variable would do "clear
functions" as a side effect.

> 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.
>

Plus you have to declare it (if a global variable). Yes, of course
this is possible, but you see that the convenience is gone. In C, you
could also use #ifndef NDEBUG instead of assert.

> Is that good enough?

It's not a solution - the problem was to optimize out asserts while
preserving the syntax. I've been using assert a lot recently, and I
was wondering whether I need to remove them. Eventually, I realized
that a simple sed script that comments/uncomments asserts is good
enough for my purposes.


>
> | 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.
>


That's what I had in mind, actually. I just thought you could specify
something like:

function_source_filter ("cpp -DNDEBUG");

to force all files being filtered through a specific program, be it
cpp or m4 or whatever. This a potentially powerful feature, but I'm
afraid it could also bring problems.


-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz