RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

-----Non-member submission-----
From: Will Adams [mailto:wadams@freescale.com] 
Sent: Tuesday, August 15, 2006 5:25 PM

This discussion (at least the part of it in which I have been involved),
started with a note I sent to Mike Burns, which he forwarded to sv-bc. 
In that note, my main point was that the statement in section 5.1.2
`Operator precedent' in IEEE 1364-2005, `Associativity refers to the
order in which the operators having the same precedence are evaluated'
is, in my view, misleading if not wrong.

The main problem is that it talks about order of evaluation of
_operators_. Short-circuit evaluation concerns the order of evaluation
of _operands_. The fact that `a+b+c' is parsed as `(a+b)+c' (because `+'

associates left-to-right) means that the LH `+' is evaluated before the
RH `+'. This is because an operand must be evaluated before its parent
operator. Associativity says nothing about the relative order of
evaluating the operands of a single operator (so `a' and `b' may be
evaluated in any order, or concurrently).

I think that the sentence quoted above should be removed from the
Standard and replaced with something like `Together, operator
precendence and associativity define a unique parse tree for expressions
that are not fully parenthesized.'

The reference to `operator evaluation order' is particularly confusing
in the case of the conditional operator, where the associativity (ie,
the `operator evaluation order', according to the Standard) is
right-to-left, but the _operand_ evaluation order is left-to-right.

I agree with Stephen's reading that the current wording of the Standard
seems to imply short-circuit evaluation for `?:'. But when I proposed a
change to the definition of `?:' to make this explicit, there were some
different opinions expressed. I think an explicit statement one way or
the other would be helpful.

will



Steven Sharp wrote:
>> From: Will Adams [mailto:wadams@freescale.com]
>>
>> The expression `h == null || h.data == 5' requires short-circuit 
>> evaluation to avoid an illegal null dereference.
> 
> Situations involving && and requiring short-circuiting may seem more 
> natural than ones involving ||.  However, ones involving || can come 
> up quite easily.  Applying DeMorgan's law to an expression involving 
> && that requires short-circuiting, can result in an expression 
> involving
> || that requires short-circuiting.  Will's example is a case of this,
> where !(h != null && h.data != 5) would be clumsy and hard to read.
> 
> Unlike &&, you cannot get the effect of a short-circuiting || just by 
> a simple nesting of if-statements.
> 
> 
>> I think the Standard should be changed as follows.
>>
>> (A) Operators `&&', `||' and `?:' are short-circuiting.
> 
> I think we are already OK on `?:'.  Section 4.1.13 says that if 
> expression 1 is false, then expression3 shall be evaluated and used as

> the result.  It does not say that expression2 can also be evaluated.  
> Similarly, if expression1 evaluates to true, then
> expression2 is evaluated and used as the result.  It does not say that

> expression3 can also be evaluated.  For an unknown condition, both 
> expression2 and expression3 are evaluated.  So it already describes 
> evaluating only the expression(s) selected.
> 
> 
>> (B) Other operators must evaluate all their operands, in any order.
> 
> Requiring evaluation of other operands is fine (though of course an 
> implementation need not actually do so if it can guarantee equivalent 
> behavior).  However, the LRM specifies an evaluation order.  Relaxing 
> this would insert indeterminacy, which we are trying to reduce.  Note 
> again that an implementation is free to pick any actual order it 
> likes, as long as the behavior is the same as the specified order.  So

> this does not constrain implementations except in the cases where it 
> would affect behavior.  And in those cases, you want to specify what 
> the behavior should be.
> 
>> An implementation is allowed to avoid evaluating `a' in `a & b' when
`b'
>>
>> is 0, provided evaluating `a' has no observable side-effects. This 
>> has the same observable effect as applying rule (B).
> 
> There is no need to specify this.  The LRM can only specify the 
> behavior of the language, not the implementation technique.  Any 
> implementation that produces the specified behavior is compliant, 
> regardless of its internal details.  So if short-circuiting or 
> changing the evaluation order has no visible effects, an 
> implementation is free to do so as an optimization.  After all, how
can you prove it is noncompliant?
> 
> Steven Sharp
> sharp@cadence.com
> 
>