Warmke, Doug wrote: > Does anyone else dissent to establishing conventional > short-circuiting behavior for || and && besides Brad? I, too, would prefer not to define these as short-circuiting. While I appreciate a general appeal to be similar to C (a language that I'm not embarassed to say that I love dearly!), in this issue I don't agree, because I believe that for SystemVerilog, hardware intuitions, and not software intuitions of process-based simulation, should be the driving factor, and it makes much more HW sense to me to make these operators strict (evaluate both ops) and symmetric (a op b is same as b op a). Also, I suspect that all our friends who hope to write formal verification tools for SV would prefer a strict, symmetric operator. Nikhil Warmke, Doug wrote: > Well, *avoiding* the side effect of a crash is a good thing. > > I think everyone agrees that this functionality can be had in > various ways. > > The point is that short-circuiting is a long and established > practice in programming. Experienced C programmers rely on > it all the time, and it's easy to read other people's code > that relies on it. Reading the ternary operator example > is tougher... I had to study it a bit to see what was > going on. > > If SystemVerilog establishes short-circuiting in a way > consistent with C, it will help adoption and appreciation > of the language by most users. > > Does anyone else dissent to establishing conventional > short-circuiting behavior for || and && besides Brad? > > Regards, > Doug > >> -----Original Message----- >> From: owner-sv-bc@server.eda-stds.org >> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Brad Pierce >> Sent: Tuesday, August 15, 2006 1:04 PM >> To: sv-bc@server.eda-stds.org >> Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005] >> >> Note that in this example, there are no side-effects in the >> disjunction. >> >> >> Also, I don't see the big advantage of || vs. ?:. >> >> contextList = findContext(scope, name, flags, &remainder); >> if ( contextList ? remainder[0] != '\0' : FALSE ) { >> >> ... >> >> -- Brad >> >> -----Original Message----- >> From: Warmke, Doug [mailto:doug_warmke@mentor.com] >> Sent: Tuesday, August 15, 2006 12:42 PM >> To: Brad Pierce; sv-bc@eda-stds.org >> Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005] >> >> Of all the things, I just took advantage of this while >> writing some code >> yesterday: >> >> contextList = findContext(scope, name, flags, &remainder); >> if (!contextList || remainder[0] != '\0') { >> ... >> >> "remainder" is not initialized if the function returns NULL. >> So I don't want to dereference it with [0] in that case. >> C's short-circuiting disjunction guarantees this won't happen. >> >> Regards, >> Doug >> >> >>> -----Original Message----- >>> From: owner-sv-bc@server.eda-stds.org >>> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Brad Pierce >>> Sent: Tuesday, August 15, 2006 12:28 PM >>> To: sv-bc@server.eda-stds.org >>> Cc: michael.burns@freescale.com; wadams@freescale.com >>> Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005] >>> >>> 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 >>>> >>>> >>> >> >Received on Tue Aug 15 18:13:24 2006
This archive was generated by hypermail 2.1.8 : Tue Aug 15 2006 - 18:13:32 PDT