RE: [sv-bc] Function call without parenthesis

Mac,

It is illegal in 1364 because there is a semicolon in the range :)

"first" is not a reserved keyword. It is a built-in method. I'm sure
this is not documented, but I believe that the identifiers for built-in
methods are reserved in the local scope where they are defined.

The labels of an enumeration are not created in their own local scope,
so it is perfectly legal to have a label called "first". So if f1 is an
enumerated variable, f1.first is unambiguously  reference to the
built-in method.

Dave


> -----Original Message-----
> From: Michael (Mac) McNamara [mailto:mcnamara@cadence.com]
> Sent: Wednesday, December 14, 2005 11:12 AM
> To: Rich, Dave; Paul Graham
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Function call without parenthesis
> 
> 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