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

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

The expression `h == null || h.data == 5' requires short-circuit
evaluation to avoid an illegal null dereference. Ada uses the name `or
else' for this operator (and the name `and then' for the short-circuit
conjunction). Whenever a condition is naturally expressed with `or else'

  (eg, `h is null or else h.data is 5') or `and then', we can use
short-circuit evaluation.

I agree that short-circuit evaluation is not the best choice for all
conjunctions or disjunctions. For simple conditions where there is no
problem of run-time errors, evaluating both operands in parallel will
give better performance.

I think the Standard should be changed as follows.

(A) Operators `&&', `||' and `?:' are short-circuiting.

(B) Other operators must evaluate all their operands, in any order.

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

will


Brad Pierce wrote:
> What's an example of the usefulness of C's left-to-right 
> short-circuiting disjunction?
> 
> -- Brad   
> 
> -----Original Message-----
> From: Will Adams [mailto:wadams@freescale.com]
> Sent: Tuesday, August 15, 2006 6:26 AM
> To: Brad Pierce
> Cc: sv-bc@eda-stds.org; michael.burns@freescale.com
> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
> 
> The `&&&' operator can only appear in limited syntactic contexts. The 
> following reasonable uses of conjunction are not allowed by the
syntax.
> 
>    c = a &&& b ;
>    if ( ! ( a &&& b ) )
> 
> The second of these is a problem because there is no `|||' short 
> circuiting disjunction, and the syntax does not allow this operation 
> to be expressed with `!' and `&&&'.
> 
> If `&&' is not required to have short-circuit evaluation, and `&&&' is

> suggested as an alternative for cases where short-circuiting is 
> desired, we have a situation where a familiar operator has unfamiliar 
> semantics, and the familiar semantics are only available in limited 
> contexts from an unfamiliar operator.
> 
> will
> 
> 
> Brad Pierce wrote:
>>> It sounds like '&&&' is not appropriate to use as a general-purpose
>> short-circuit
>>> logical AND.
>> Because &&& allows the
>>
>>      expression 'matches' pattern &&& ...
>>
>> syntax, it can do *more* than a general-purpose short-circuit logical

>> AND.  How does its greater generality make it inappropriate for a 
>> more
> 
>> restrictive purpose?
>>
>> Regardless of the original reasons for introducing
>>
>>     if (expression &&& expression)
>>
>> it behaves exactly like C users have come to expect from
>>
>>     if (expression && expression)
>>
>> .
>>
>> -- Brad
>>
>> -----Original Message-----
>> From: Steven Sharp [mailto:sharp@cadence.com]
>> Sent: Monday, August 14, 2006 2:43 PM
>> To: Brad.Pierce@synopsys.COM; nikhil@bluespec.com
>> Cc: wadams@freescale.com; sv-bc@eda-stds.org; 
>> michael.burns@freescale.com
>> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
>>
>>
>>> From: "Rishiyur Nikhil" <nikhil@bluespec.com> '&&&' is not merely a 
>>> conjunction operator, and its reason for existence is not to 
>>> introduce short-circuiting-- it is because it has
> 
>>> a
>>> variable-binding function unique to the pattern-matching facilities 
>>> of the language.
>> Thanks for the explanation.  It sounds like '&&&' is not appropriate 
>> to use as a general-purpose short-circuit logical AND.
>>
>> Steven Sharp
>> sharp@cadence.com
>>
>>
>