Yes, there is a deliberate reason why '&&&' can only appear in limited syntactic contexts, why it is asymmetric (left to right) and why there is no corresponding '|||' (I repeat below my explanation from yesterday about this), The motivation for '&&&' is not short-circuiting, but pattern-matching. '&&&' is intended to be used only with pattern-matching in conditionals (because of its variable-binding and scoping function), and is not intended as a general-purpose binary logical operator. True, the syntax allows it to be used as a short-circuiting conjunction at the top-level of conditionals, but that is an accidental consequence, and not the purpose of the operator. If we want a separate short-circuiting logical conjunction and disjunction (which are orthogonal to pattern-matching and can be used in any expression context), then that needs to be a separate discussion (not involving '&&&'). Regards, Nikhil ---------------------------------------------------------------- Repeating explanation from yesterday: There are specific reasons for these language design choices. '&&&' 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. If the left-hand operand is matching pattern, then it can also introduce and bind identifiers from the pattern in the left-hand operand, which are then in scope and available in the right-hand operand and in the 'then' part of the conditional. This is the reason why: - it is only at the top-level of conditionals (if it was nested more deeply, what would be the scope of the pattern variables?) - it is assymmetric, left-to-right (the pattern variables in the right-hand operand only make sense if the left-hand match succeeds) - there is no corresponding '|||' (again, the pattern variables in the right-hand operand only make sense if the left-hand match succeeds) ---------------------------------------------------------------- Brad Pierce wrote: > -----Non-member submission----- > From: Will Adams [mailto:wadams@freescale.com] > Sent: Tuesday, August 15, 2006 6:26 AM > 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 10:09:24 2006
This archive was generated by hypermail 2.1.8 : Tue Aug 15 2006 - 10:09:31 PDT