RE: [sv-ec] Invalid example of srandom - mantis 1391

 

Omitting . in table 8-1 was not a mistake. It was intentional. '.' was not
an operator in 
1364 (same for []) and should never have been in the table.

Table 8.3 lists things which are not operators: (), . , [], 
I do not understand why () are operators.

Francoise
    '



-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Warmke,
Doug
Sent: Friday, March 24, 2006 12:42 PM
To: Arturo Salz; Rich, Dave; Brad Pierce; sv-ec@eda.org
Subject: RE: [sv-ec] Invalid example of srandom - mantis 1391

I'm not sure, but maybe Dave is getting at an issue like the following:

module m;
class c;
   int i;
endclass
c ic = new;
function c f();
   int i;
   return ic;
endfunction
initial begin
   $display("m.f().i = %0d", m.f().i); // should print c's i
   $display("m.f.i = %0d", m.f.i);     // should print f's i
end
endmodule

Unfortunately I'm in a strange location, without access to the LRM or my
handy SystemVerilog compiler.

Is the optional parentheses for function calls available in hierarchical
reference context?  I don't believe it should be, but not sure if the LRM
states that.  This should be looked into and followed up if needed.

Would this syntactic distinction be enough to disambiguate the case you
brought up, Dave?

Regards,
Doug

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
> Arturo Salz
> Sent: Friday, March 24, 2006 12:41 AM
> To: Rich, Dave; Brad Pierce; sv-ec@eda.org
> Subject: RE: [sv-ec] Invalid example of srandom - mantis 1391
> 
> Dave,
> 
> The fact that it appears in any table at all means that the intent was 
> certainly to have '.' as an operator. In fact, the SystemVerilog-3.1a 
> LRM includes only one such table to list all operators: Table
> 7-2 which
> became Table 8-3 in P1800. When Table 8-1 was added to P1800, the 
> editor omitted the '.' operator (it was mostly likely done by editing 
> an older version of the operator table). Thus, to attempt to conclude 
> intent from a popularity contest is plain wrong. The only sensible 
> thing to do is to call this what it is: "a typo". Then the course of 
> action is clear: we fix it, and move on.
> 
> I'm not sure I understand your point about 12.3.1 becoming ambiguous.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
> Rich, Dave
> Sent: Wednesday, March 22, 2006 11:19 AM
> To: Brad Pierce; sv-ec@eda.org
> Subject: RE: [sv-ec] Invalid example of srandom - mantis 1391
> 
> Brad,
> 
> But it's not listed as an operator in syntax box 8-1 or table 8-2, so 
> best 2 out of three wins. :)
> 
> There's a bigger issue in that allowing a function name in the middle 
> of a hierarchical path would create an ambiguity between referencing a 
> member of that function or a member of the class the function is 
> pointing to. See 12.3.1
> 
> Dave
> 
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Brad
> > Pierce
> > Sent: Wednesday, March 22, 2006 7:49 AM
> > To: sv-ec@eda.org
> > Subject: Re: [sv-ec] Invalid example of srandom - mantis 1391
> > 
> > method_call_root was not just added to handle 'this' and
> 'super', but
> to
> > support method calls for any expressions that yield handles allowing 
> > such calls.
> > 
> > An example like the following from 7.11
> > 
> >    p.next.next.next.val
> > 
> > would still be legal as
> > 
> >    p.next().next().next().val
> > 
> > Otherwise one could only chain through a sequence of handles using 
> > default argument values.
> > 
> > -- Brad
> > 
> > p.s. According to Table 8-3, dot is an operator.
> > 
> > 
> > -----Original Message-----
> > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > Sent: Tuesday, March 21, 2006 10:59 PM
> > To: Brad Pierce; sv-ec@eda.org
> > Subject: RE: [sv-ec] Invalid example of srandom - mantis 1391
> > 
> > Brad,
> > 
> > ERR-47 was added to allow things like this.method_call() and 
> > super.method_call(). It still does not make '.' an operator.
> > 
> > > -----Original Message-----
> > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
> Behalf Of
> > Brad
> > > Pierce
> > > Sent: Tuesday, March 21, 2006 10:29 PM
> > > To: sv-ec@eda.org
> > > Subject: Re: [sv-ec] Invalid example of srandom - mantis 1391
> > >
> > > >That would be true if '.' was defined as an operator,
> but it's not
> in
> > > >SystemVerilog; it's a hierarchical identifier separator.
> > >
> > > That interpretation is not consistent with
> > >
> > >    http://www.eda.org/sv-ec/Errata/ERR_47.html
> > >
> > > which introduced "method_call_root" to the BNF on Dec. 15, 2003
> > >
> > >
> http://www.eda.org/sv-ec/Minutes/SV-EC-Minutes-2003-December-15.txt
> > >
> > > See also
> > >
> > >    http://www.eda.org/sv-bc/hm/1733.html
> > >
> > > -- Brad
> > >
> > >
> > 
> 
> 
> 
>