[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stupid Matlab-style short-circuit behavior for | and &
From: |
Jaroslav Hajek |
Subject: |
Re: stupid Matlab-style short-circuit behavior for | and & |
Date: |
Thu, 7 Oct 2010 17:00:57 +0200 |
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?
- stupid Matlab-style short-circuit behavior for | and &, John W. Eaton, 2010/10/07
- Re: stupid Matlab-style short-circuit behavior for | and &, Søren Hauberg, 2010/10/07
- Re: stupid Matlab-style short-circuit behavior for | and &, CdeMills, 2010/10/07
- Re: stupid Matlab-style short-circuit behavior for | and &,
Jaroslav Hajek <=
- Re: stupid Matlab-style short-circuit behavior for | and &, John W. Eaton, 2010/10/07
- Re: stupid Matlab-style short-circuit behavior for | and &, Jaroslav Hajek, 2010/10/07
- Re: stupid Matlab-style short-circuit behavior for | and &, John W. Eaton, 2010/10/07
- Re: stupid Matlab-style short-circuit behavior for | and &, Jaroslav Hajek, 2010/10/08
- Re: stupid Matlab-style short-circuit behavior for | and &, John W. Eaton, 2010/10/08
- Re: stupid Matlab-style short-circuit behavior for | and &, Søren Hauberg, 2010/10/09
- Re: stupid Matlab-style short-circuit behavior for | and &, Ben Abbott, 2010/10/09
- Re: stupid Matlab-style short-circuit behavior for | and &, John W. Eaton, 2010/10/09
- Re: stupid Matlab-style short-circuit behavior for | and &, Jaroslav Hajek, 2010/10/09
- Re: stupid Matlab-style short-circuit behavior for | and &, Søren Hauberg, 2010/10/09