RE: [sv-bc] Function call without parenthesis

I think there is a backward compatibility issue, because some tools have
already implemented SV method calls without parentheses.  Personally, I
would have been fine with a rule that method calls always needed
parentheses, but think it is too late now.

I agree that Greg's example, below, brings up a good point that needs
clarification in the LRM.  From a user's perspective, I would expect that
trial.first would return the enumerated value (1), and that to get to the
method would require explicitly specifying the parentheses; trial.first().
In other words, the search order for "first" is too look for the enumerated
labels first.

Just my $.02, from a user's point of view.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Greg Jaxon
> Sent: Wednesday, December 14, 2005 11:28 AM
> To: sv-bc@eda.org
> Subject: Re: [sv-bc] Function call without parenthesis
> 
> More to the point would be this example:
> 
>     typedef enum {
>        original=0,
>        first=1,
>        second,
>        third,
>        penultimate,
>        last,
>        out_of_bounds
>     } trial;
> 
> Is trial.first  equal to 0 or 1?  How about trial.first()?
> 
> Greg Jaxon
> 
> Michael (Mac) McNamara wrote:
> > Backward incompatible with what?  I'm going down a 
> different path.  I am
> > afraid that 
> > allowing variable attribute inquiry functions to look like 
> hierarchial
> > references 
> > _introduces_ backwards incompatibility of 1800 with 1364.
> > 
> > I will ask my backward incompatibility question again.
> > 
> > Is the following 1364 code legal in 1800? :
> > 
> > module foo;
> >    reg [31;0] first;
> > endmodule
> >  
> > Perhaps it is not legal in 1800 because "first" is now a 
> reserved word.
> > Or perhaps it is still legal, as the only restricted use of 
> first is as
> > a variable attribute inquiry method call.
> > 
> > If it is still legal to have the module foo above in 1800, 
> then the next
> > question is concerning the legality of this 1364 complaint code:
> > 
> > module foo;
> >    reg [15:0] first;
> >    initial first = 6144;
> > endmodule
> > 
> > module bar;
> >    foo f1();
> >    initial #10 $display("f1.first is %x compliant",f1.first);
> > endmodule
> > 
> > Is this above code legal in 1800?  If it is, then I submit 
> that we will
> > be confusing users as we also allow f1.first to ask about a variable
> > named f1 that is an enum. (similarily with len, size, et cetera)
> > 
> > Michael McNamara
> > mcnamara@cadence.com
> > 408-914-6808 work
> > 408-348-7025 cell
> > 
> > 
> > -----Original Message-----
> > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> > Rich, Dave
> > Sent: Wednesday, December 14, 2005 10:21 AM
> > To: Paul Graham
> > Cc: sv-bc@eda.org
> > Subject: RE: [sv-bc] Function call without parenthesis
> > 
> > Paul,
> > 
> > This is a backward incompatible change. Can you provide the 
> technical
> > justification for this? I'm not saying there is no 
> justification; just
> > that it needs to be explained for us to move on it. So far 
> I have heard
> > nothing other than editorial comments.
> > 
> > Dave
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Paul Graham [mailto:pgraham@cadence.com]
> >>Sent: Wednesday, December 14, 2005 10:14 AM
> >>To: Rich, Dave
> >>Cc: sv-bc@eda.org
> >>Subject: Re: [sv-bc] Function call without parenthesis
> >>
> >>
> >>>Welcome to the wonderful world of object oriented programming. You
> >>>should be glad SystemVerilog didn't put in all of C++.
> >>
> >>Too bad.  I notice that C++ doesn't follow the UAP for
> >>function calls of no arguments.  In fact, requiring parens
> >>makes it possible to define operator().  Try doing that in
> >>Ada!
> >>
> >>As a technical issue, I'd like to suggest that () be
> >>required on a function or method call of no args, except in
> >>the case of a system function or task.
> >>
> >>Paul
> > 
> > 
> > 
> 
> 
>