Re: stupid Matlab-style short-circuit behavior for | and &

[Jaroslav Hajek]

On Thu, Oct 7, 2010 at 12:05 PM, John W. Eaton <address@hidden> wrote:
> I'm considering applying the following patch so that Octave can be
> compatible with the stupid Matlab-style short-circuit behavior for the
> normally element-by-element | and & operators.
>
> No, I have not (entirely) lost my mind.  I made this change in
> response to a request from someone who is paying for support.  I still
> think this is a really really stupid feature, but I don't see the harm
> if it is off by default and only enabled in --traditional AKA
> --maximum-braindamage mode, or if you explicitly set the
> do_braindead_shortcircuit_evaluation pseudo-variable to true.  The
> help text for that function specifically warns against using this
> feature in new code and recommends the || and && operators.
>
> Since it only affects the way that expressions are evaluated and not
> the way they are parsed, the feature can be toggled at run time.  For
> example:
>
>  octave> function r = z (a), disp ('in z'); r = a; end
>  octave> function f (a), if (a | z (0)) end, end
>  octave> do_braindead_shortcircuit_evaluation (1)  ## short-circuit
>  octave> f(1)
>  octave> do_braindead_shortcircuit_evaluation (0)  ## no short-circuit
>  octave> f (1)
>  in z
>
> I'm definitely not encouraging the use of this feature.  We should
> probably ensure that there are no | or & expressions in IF or WHILE
> statements within Octave itself that could be misinterpreted if this
> feature is enabled.  Perhaps there should also be a warning (issued
> by the parser) about expressions that are marked as eligible for this
> kind of short-circuit evaluation?  That would make finding them
> slightly easier.
>
> Are there any strong objections to making this change?
>
> jwe
>

I think the case is analogous to the non-integer ranges, so the
general idea is OK. What I see as a downside of this solution is that
*each* binop node gets an extra flag, which will make all expression
trees consume more space just because of a stupid feature.

Here's an alternative idea: Maybe it would be be better to make
tree_expression::is_logically_true accept an optional short_circuit
flag and then override this method directly in tree_binary_expression
to do the right thing?
It would then suffice to call
expr->is_logically_true ("if", Vdo_braindead_shortcircuit_evaluation)
from within pt-eval.cc at all appropriate places (also in while,
perhaps in until for consistency?)

I can even prepare a patch, but it will take some time, I'm busy with
the new job and relocation process.

regards

PS. Is this the same customer who wanted the non-integer ranges? How
many do you have, if that's not a secret?