On Wed, Sep 24, 2014 at 12:14 PM, Mike Cowlishaw <[email protected]>
wrote:
>
>
> However, I want to circle back around to the discussion of the
>> short-circuited AND. We can't eliminate the usage on IF/WHEN, etc., but on
>> the other hand, there are certainly contexts where an and operator that
>> uses short-circuit logic might be useful. One could argue that an OR
>> version could also be useful. I don't believe this is possible for XOR,
>> since the result always depends on both values. Are there any operator
>> combinations that would make sense? Doubling up obviously doesn't work
>> because && and || are already operators.
>>
>> Another thought: perhaps
>>
>> ,& and ,|
>>
>> are the bail-out AND and OR,
>>
>> and in IF and WHEN context ',' expression separator "implies" the OR (|).
>>
>> the IF/WHEN context is an AND, not an OR. The condition is only true if
> all of the subexpressions are true, but will stop evaluating with the first
> false result. An OR equivalent would stop evaluation with the first true
> result.
>
> Ouch, that's different to the NetRexx definition, which is the OR
> case. (The first case that succeeds wins.) Or are we just
> reading/defining it differently?
>
>>
>> So:
>>
>> If a=b ,| c=d then ...
>>
>> would be identical to:
>>
>> if a=b, c=d then ...
>>
>> Mike
>>
>>
Ouch indeed. I'm afraid I did misread (or misremembered) how this was
defined in NetRexx and implemented it the other way. I think, in general,
this is much more useful as an AND case as it does not require the
cascading IF--THEN statements and is generally easier to handle with the
ELSE case. And on a When clause, you can't even do the cascade to allow it
to go to the next clause.
Rick
>
> Not sure I like using the comma here...it's already feeling a bit
> overloaded now. In some contexts, it's an expression delimiter, in others,
> it is part of an operator. The "+&" doesn't seem too bad, but I'm not sure
> if the OR case should be "-|" or also "+|". I had also considered "\&" and
> "\|", since that is already used as a modifier to a lot of the comparison
> operators. Of course, that opens the question on whether the logical not
> character needs to be supported too.
>
> I'm looking for an overarching rule here. Something like:
>
> expr, expr, expr -- makes an array
>
> expr, | expr, | expr -- ORs each expression together, but allows
> early bailout if the completed expression(s) settle the result
>
> the | can be omitted in IF/WHEN case because an array result is not
> allowed.
>
> But yes, it's a bit of a stretch.
>
> Mike
>
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Oorexx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
