RE: [sv-champions] Champions conference call May 21st, 2009 -- 2735

Brad,

You wrote in the description of Mantis 618 (http://eda.org/mantis/view.php?id=618), 

"you can call expr.method for any expression that returns an object. You are not restricted to identifier.method."

I asked you about that, and you pointed to http://www.eda-twiki.org/sv-ec/hm/1519.html, as below, and in addition,

"This was ERR-51, see http://www.eda-stds.org/sv-ec/Minutes/SV-EC-Minutes-2003-December-1.txt".

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-champions@server.eda.org 
> [mailto:owner-sv-champions@server.eda.org] On Behalf Of Brad Pierce
> Sent: Thursday, May 21, 2009 9:14 AM
> To: sv-champions@eda.org
> Subject: RE: [sv-champions] Champions conference call May 
> 21st, 2009 -- 2735
> 
> Dave,
> 
> In the following BNF erratum/proposal from 2003
> 
>       http://www.eda-twiki.org/sv-ec/hm/1519.html
> 
> the first bug I described was exactly a lack of method call chaining
> 
>      "Only accepts method calls for identifiers, instead
>       of for any expression that yields a type that allows
>       a method call."
> 
> That initial fix, early in Accellera 3.1a, was then built on by
> 
>     http://www.eda-twiki.org/sv-ec/hm/1623.html
>     http://www.eda-twiki.org/sv-ec/hm/1643.html
>     http://www.eda-twiki.org/sv-ec/hm/1715.html
> 
> and most recently, during work on 1800-2009, by
> 
>     http://www.eda-stds.org/svdb/view.php?id=1480
> 
> which was discussed here
> 
>       
> http://www.eda-twiki.org/sv-ec/Minutes/SV-EC_Meeting_September_11_20
> 06_Minutes.txt
>       
> http://www.eda-twiki.org/sv-ec/Minutes/SV-EC_Meeting_October_9_2006_
> Minutes.txt
> 
> Because the BNF has long accepted method call chaining and 
> there seems to be no prohibition on it in the text, I believe 
> it's allowed unless the committee adds an explicit 
> deprecation.  The proposed resolution is not accurate.
> 
> For completeness, here's an example BNF derivation of 
> obj.method1(5).method2(6)
> 
>        expression ::= primary
>                         ::= function_subroutine_call
>                         ::= subroutine_call
>                         ::= method_call
>                         ::= method_call_root . method_call_body
>                         ::= primary . method_identifier ( 
> list_of_arguments )
>                         ::= function_subroutine_call . method2(6)
>                         ::= subroutine_call . method2(6)
>                         ::= method_call . method2(6)
>                         ::= method_call_root . 
> method_call_body . method2(6)
>                         ::= primary . method_identifier ( 
> list_of_arguments ) . method2(6)
>                         ::= obj . method1(5) . method2(6)
> 
> -- Brad
> 
> 
> ________________________________________
> From: Rich, Dave [Dave_Rich@mentor.com]
> Sent: Wednesday, May 20, 2009 3:55 PM
> To: Brad Pierce; sv-champions@eda.org
> Subject: RE: [sv-champions] Champions conference call May 
> 21st, 2009 -- 2735
> 
> Brad,
> 
> The example in 8.11 has (relatively) well defined namespace search
> rules, because after the first name, everything is a field or property
> select.
> 
> What happens if you allow method calls, and that name is not found
> locally? Do normal Verilog hierarchical search rules apply? In the
> middle of dotted name? What about static variable names inside
> functions?
> 
> There are not very hard problems to solve, but just not in 
> the timeframe
> we have for the ballot.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: owner-sv-champions@server.eda.org [mailto:owner-sv-
> > champions@server.eda.org] On Behalf Of Brad Pierce
> > Sent: Wednesday, May 20, 2009 3:21 PM
> > To: sv-champions@eda.org
> > Subject: RE: [sv-champions] Champions conference call May 21st, 2009
> --
> > agenda
> >
> > Neil,
> >
> > On Mantis 2735, I don't understand the ballot issue or its 
> resolution.
> > Can't method calls be chained?  For example, as in 8.11
> >
> >    Third, instance qualifications can be chained as needed to reach
> into
> > objects or to reach through objects:
> >
> >              p.next.next.next.val // chain through a sequence of
> handles to
> > get to val
> >
> > -- Brad
> >
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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.