Brad Pierce wrote: > What is meant by the "top-level" of conditionals? What I mean is that, in the BNF for 'conditional_statement' and 'conditional_expression' the BNF is structured so that '&&&' can only be used at the top level of the predicate (it is a 'cond_predicate' which can use '&&&', inside which are general expressions, which cannot use '&&&'). Brad Pierce wrote: > Why should it matter to a user what the original "purpose" of an > operator was? It shouldn't matter to a user; the LRM should be clear and precise, and adequate. I'm bringing up "purpose" in this forum because we are considering changes and improvements, and I want to explain why the '&&&' construct was designed that way, and what are the consequences of the changes being considered (making it a general binary op, introducing '|||', etc.). Regards, Nikhil Brad Pierce wrote: > What is meant by the "top-level" of conditionals? > > Why should it matter to a user what the original "purpose" of an > operator was? > > -- Brad > > -----Original Message----- > From: Rishiyur Nikhil [mailto:nikhil@bluespec.com] > Sent: Tuesday, August 15, 2006 10:09 AM > To: Brad Pierce; sv-bc@eda-stds.org > Cc: michael.burns@freescale.com; wadams@freescale.com > Subject: Re: FW: [sv-bc] [Fwd: Issues with IEEE 1364-2005] > > 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 Wed Aug 16 07:03:29 2006
This archive was generated by hypermail 2.1.8 : Wed Aug 16 2006 - 07:03:37 PDT