RE: [sv-ac] Reviewing 3191 (triggered method on sequence formals)

Like enum.first, right?

So is sequence.triggered different?

If so, why?

Thanks,
Shalom

From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Monday, March 14, 2011 1:08 AM
To: Bresticker, Shalom; sv-ac@eda.org
Subject: RE: [sv-ac] Reviewing 3191 (triggered method on sequence formals)

Shalom,

This mean means that built-in identifiers are reserved in certain scopes, but do not need to be treated as keywords to be parsed.

Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439
[cid:image001.png@01CBE245.C71257C0]<http://www.twitter.com/dave_59>[cid:image002.png@01CBE245.C71257C0]<http://go.mentor.com/drich>

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bresticker, Shalom
Sent: Sunday, March 13, 2011 12:40 AM
To: sv-ac@eda.org
Subject: RE: [sv-ac] Reviewing 3191 (triggered method on sequence formals)

I thought that method calls are handled by the following part of the BNF (A.8.2 Subroutine calls):

subroutine_call ::=
  tf_call
| system_tf_call
| method_call
| [ std:: ] randomize_call

method_call ::= method_call_root . method_call_body

method_call_body ::=
  method_identifier { attribute_instance } [ ( list_of_arguments ) ]
| built_in_method_call

method_call_root ::= primary | implicit_class_handle

Shalom

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Rich, Dave
Sent: Friday, March 11, 2011 8:31 PM
To: Kulshrestha, Manisha
Cc: Seligman, Erik; sv-ac@eda-stds.org
Subject: Re: [sv-ac] Reviewing 3191 (triggered method on sequence formals)

That is exactly why, plus it keeps the BNF simple.

-Dave

Sent from my iPhone

On Mar 11, 2011, at 10:15 AM, "Kulshrestha, Manisha" <Manisha_Kulshrestha@mentor.com<mailto:Manisha_Kulshrestha@mentor.com>> wrote:
Hi,

I do not know why but that is the case with different kinds of methods e.g. .first on enums or .size for arrays. This way, these method names are not keywords and the tool can identify them based on the usage. This is a big advantage as adding new keyword for each new method is not a good idea.

Manisha

________________________________
From: Seligman, Erik [mailto:erik.seligman@intel.com]
Sent: Friday, March 11, 2011 11:33 PM
To: Kulshrestha, Manisha; sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>
Subject: RE: [sv-ac] Reviewing 3191 (triggered method on sequence formals)
OK… So you are saying .triggered is treated as a hierarchy during parsing? Why is it done this way? It seems like something very different to me.


From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentor.com]
Sent: Friday, March 11, 2011 9:32 AM
To: Seligman, Erik; sv-ac@eda-stds.org<mailto:sv-ac@eda-stds.org>
Subject: RE: [sv-ac] Reviewing 3191 (triggered method on sequence formals)


Hi Erik,

There is nothing special about triggered. Whenever parser sees something like s.triggered or f.triggered it just knows that it is a hierarchical reference which is also part of primary in the expression. So this gets parsed as an expression (it is the job of the tool to figure out that this is method .triggered defined for sequences):

primary ::=

primary_literal

| [ class_qualifier | package_scope ] hierarchical_identifier

hierarchical_identifier ::= [ $root . ] { identifier constant_bit_select . } identifier



Now consider the case (a ##1 b).triggered, I do not think there is anything in the bnf of expression which will parse it. If we want to parse it, we'll have to define something in the bnf for the expression to take something like <sequence_expr . identifier>.
Thanks.
Manisha
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.