Re: [sv-ec] Mantis 1609: New updates?

  Gordon,
 Thanks for the detailed explanation. I agree totally and understand your assessments of the situation. 
 I wrote an email to the vendor that accepts the import of packages within a class, recommending that that be disallowed. 
 Since vendors see this email, I hope that those that are not compliant to this mantis start to make implement the change for their next release. 
 Thanks Gordon,
 Ben
   ---------------------------------------------------------------------------
 Ben Cohen http://www.systemverilog.us/ 
    
 -----Original Message-----
 From: gordonv@model.com
 To: vhdlcohen@aol.com
 Cc: sv-ec@server.eda.org
 Sent: Sun, 5 Nov 2006 8:47 PM
 Subject: Re: [sv-ec] Mantis 1609: New updates?
 
  Ben, 
 
 The basic point is that the interaction of name resolution rules 
 involving import and inheritance becomes very muddled. 
 
 For example, 
 
 class C; 
 int x; 
 endclass 
 
 package p; 
 int x; 
 endpackage 
 
 class D extends C; 
 import p::*; 
 function f(); 
 return x; // is this this.x (from C) or p::x 
 endfunction 
 endclass 
 
 class E extends D; 
 function int g(); 
 return x + super.x; // what is "x"? what is "super.x"? 
 endfuntion 
 endclass 
 
 C++, in order to avoid this issue, also disallows using 
 a namespace in a class scope. Either outside the class 
 or in a method there is never confusion between inheritance 
 and package (namespace) visibility. Mixing the two is 
 very confusing in practice and can lead to very subtle issues. 
 
 Complicating the issue is the question of whether imported 
 visibility is inherited. If not, then the meaning of "x" 
 in a class E derived from D reverts back to the inherited 
 member, not the package element. That sounds pretty scary 
 (no override of "x" but the meaning changes). If one would 
 say that the package visibility is inherited then how 
 is it inherited? Is an overriding declaration now an 
 error (as it would be in D following function f)? Does 
 that mean that an import is a way of saying that an identifier 
 can no longer be overridden? What about interactions with 
 virtual functions? Pure virtual functions? 
 
 There are many awkward questions here. 
 
 If a vendor allows this right now, it may be an oversight 
 or may not have intended consequences in the areas that 
 I have raised. 
 
 If it is intentional, the vendor should step up and offer 
 a sensible set of rules if they don't want it disallowed. 
 No one has done so yet. The feedback from both Synopsys 
 reps so far has been that the current LRM text overlooked this 
 case and that such imports should be disallowed. Cadence 
 didn't object to this view in SV-BC; I don't know if that 
 will change in SV-EC. 
 
 In terms of the status, I had filed this as an SV-BC 
 item (due to the imports) but BC felt that EC should 
 address the issue. So it is in the hands of EC. Due to 
 the face-to-face and on-going discussions regarding other 
 areas, I don't know where this will fall in the agenda. 
 If you consider this to be pressing, you could ask Mehdi 
 to elevate this in the agenda. At this point, given that 
 I haven't heard anything negative from any of the vendors, 
 I am expecting this to be approved when it does come up. 
 
 In terms of overall language interpretation and compliance 
 issues, yes, we are all aware of many issues in that 
 space. There are numerous ambiguities and issues that 
 are (slowly) being resolved. I am working with a sub-group 
 of SV-BC to work through name resolution issues; interpretation 
 differences in that area tend to cause compatibility issues but 
 there are many interactions that have not been carefully 
 defined so progress is slow. When there is disagreement, 
 progress tends to stop until issues are resolved. Only 
 once point issues are resolved can a comprehensive write-up 
 really have much of a chance; you can go back in SV-BC/EC 
 archives to see a writeup that I did quite a while ago 
 describing a basic framework. 
 
 And that is all just on name resolution.... 
 
 My hope is that vendors are being aggressive about complying with 
 approved Mantis items since that will aid in reaching consensus and 
 common interpretations more quickly. Past experience however 
 suggests that not everyone follows that philosophy. If you 
 are aware of vendors that don't comply with the restrictions 
 proposed in Mantis 1609, it might be worthwhile to ask them how they 
 intend to respond to it. If there is disagreement, the community 
 is far better off if the disagreement is raised early. 
 
 Gord. 
 
 vhdlcohen@aol.com wrote: 
 
 > > Mantis 1609 states 
 > Quote: 
 > It shall be illegal to have an import statement directly within a class > scope. 
 > > > 1, What is the status of this mantis? Still under discussion? > 2. If the import is outside the class and at root, then the only need > for the import would be for synthesis of RTL since the import of a > package would be seen by the RTL anyway from root. 
 > 3. Currently not all vendors have abided by current P1800 that allows > the import within a class. 
 > What about backward compatibility since current P1800 LRM allows import > within a class? Users will need to make the necessary changes. 
 > 3. As of today there are several differences in tool support and > understanding (or interpretation) of the LRM. Code that compiles and > runs on one tool would most likely not execute on another tool, > particularly when the advanced feature of the language are used. This > import issue is only one of them. 
 > [...] 
 -- -------------------------------------------------------------------- 
 Gordon Vreugdenhil 503-685-0808 
 Model Technology (Mentor Graphics) gordonv@model.com 
   
________________________________________________________________________
Check out the new AOL.  Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.