My recollection was that we only took a formal vote on the second question. And in fact, that proposal is worded in the opposite sense of my e-mail (a yes vote meant chaining was not the default). My recollection of the voting was that the users were split 2 and 2, the 5 people form SNPS voted no, and the 2 people each from MENT and CDNS voted yes, so the motion failed 6 to 7 (and there might have been 1 abstention). Then the 2 users said they would change their vote to yes as long as they were given the option to allow chaining. So the first question was never asked in the committee meeting - it was just from my observation that there were enough people who thought chaining should not be the default, therefore there should be enough people that think importing without chaining is a useful feature. I just checked before sending this and see that the unapproved minutes have been posted - http://www.eda-stds.org/sv-bc/minutes/sv-bc_06_09_11.txt. Dave > -----Original Message----- > From: Logie Ramachandran [mailto:Logie.Ramachandran@synopsys.com] > Sent: Sunday, September 17, 2006 9:30 AM > To: Rich, Dave; Brad Pierce; sv-bc@eda-stds.org; SV_EC List; sv- > ac@verilog.org > Subject: RE: [sv-ec] Re: [sv-bc] explicit package exports > > Hi Dave, > > I thought in the committee that the users answered "no" to the > first question. The second question had a "yes and no" answer from the > vendors based on different interpretations. > > The users were also willing to answer "yes" to the first question > if there was a mechanism to accomplish chaining. > > Thanks Gord for coming up with an initial proposal to accomplish > chaining. > > Logie. > > -----Original Message----- > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of > Rich, Dave > Sent: Friday, September 15, 2006 11:44 AM > To: Brad Pierce; sv-bc@eda-stds.org; SV_EC List; sv-ac@verilog.org > Subject: RE: [sv-ec] Re: [sv-bc] explicit package exports > > Brad, > > I don't think anyone is disagreeing that chaining of imports would be a > useful feature for some people. > > The two questions are: is importing without chaining not a useful > feature, and does the current LRM specify that chaining of imports is > required default? > > If the answer to the first question was yes, then the second question > doesn't really matter and the LRM would need to be changed to clarify > that regardless. > > The consensus building argument in the meeting was that the answer to > both questions was no. (The actual questions may have been phrased in > the opposite sense, I can't remember until I see the minutes of the > meeting) > > Dave > > > > -----Original Message----- > > From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] > On > > Behalf Of Brad Pierce > > Sent: Friday, September 15, 2006 10:57 AM > > To: sv-bc@server.eda-stds.org; SV_EC List; sv-ac@server.verilog.org > > Subject: RE: [sv-ec] Re: [sv-bc] explicit package exports > > > > I'm reassured when I hear that a feature "does not exist in any other > > language", because I'm probably headed in the right new direction. > > > > VHDL is a great language, but there's always room for improvement > > > > http://www.accellera.org/activities/vhdl/ > > > > -- Brad > > > > -----Original Message----- > > From: Rich, Dave [mailto:Dave_Rich@mentor.com] > > Sent: Friday, September 15, 2006 9:47 AM > > To: Brad Pierce; sv-bc@eda-stds.org; SV_EC List; sv-ac@verilog.org > > Subject: RE: [sv-ec] Re: [sv-bc] explicit package exports > > > > Brad, > > > > 19.2.1 "The import statement provides direct visibility of identifiers > > within packages. It allows identifiers declared within packages to be > > visible within the *current* scope without a package name qualifier." > > > > Current scope means any statement that is a member of that scope has > > visibility to that import, and not to scopes that are not members of > > that scope. > > > > Given that this use model has been proven with VHDL, and chaining of > > package imports does not exist in any other language, I don't see why > > one would think that chaining of import is required to be useful. > > > > The agreement that we reached in the committee meeting on Monday was > > that to get consensus, we would have the default import not do > chaining > > as long as we could define an a way for the users to change the > default > > behavior. That is how we came up with the export idea. > > > > Dave > > > > > > > > > > > -----Original Message----- > > > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] > > On > > > Behalf Of Brad Pierce > > > Sent: Friday, September 15, 2006 8:31 AM > > > To: sv-bc@server.eda-stds.org; SV_EC List; sv-ac@server.verilog.org > > > Subject: Re: [sv-ec] Re: [sv-bc] explicit package exports > > > > > > Shalom, > > > > > > Package chaining seems the obvious thing when you have a mental > model > > of > > > a package reference as being like a link in a file system. In a > file > > > system, the entire chain of links behind the simple local name is > > > automatically followed by the OS until hitting the actual file. > (This > > > same mental model makes aliasing a natural idea.) > > > > > > If there were really any LRM examples that "clearly imply that > import > > > chaining was not intended", then testing with the LRM examples would > > > have revealed a mismatch between the intent and what seems obvious > > under > > > the file system analogy. > > > > > > What's most important, of course, is that the SV package mechanism > be > > as > > > usable as possible. > > > > > > -- Brad > > > > > > -----Original Message----- > > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > > > Bresticker, Shalom > > > Sent: Friday, September 15, 2006 4:26 AM > > > To: Gordon Vreugdenhil > > > Cc: sv-bc@eda-stds.org; SV_EC List; sv-ac@verilog.org > > > Subject: RE: [sv-ec] Re: [sv-bc] explicit package exports > > > > > > 'local import' could be useful together with 'export *::*' as a way > to > > > > > say, 'export everything except a particular imported item'. > > > > > > A separate question: since wildcard exports as proposed would only > > > export items actually imported and not import candidates, how could > I > > > export all of p1 to p3 via p2? I would think that could be useful. > > > > > > Finally, when I read 19.2 in 1800-2005, I think the language and the > > > examples clearly imply that import chaining was not intended. > Possibly > > > > > nobody even thought about it till now. Other interpretations of the > > text > > > are basically based on the argument that the text does not > explicitly > > > say it does not happen. I don't accept that argument. In my opinion, > > the > > > total lack of reference to it means the reverse. > > > > > > Shalom > > > > > > > -----Original Message----- > > > > From: owner-sv-ec@server.eda.org > [mailto:owner-sv-ec@server.eda.org] > > > On > > > > Behalf Of Gordon Vreugdenhil > > > > Sent: Friday, September 15, 2006 12:46 AM > > > > To: Greg Jaxon > > > > Cc: Brad Pierce; sv-bc@server.eda-stds.org; SV_EC List; sv- > > > > ac@server.verilog.org > > > > Subject: [sv-ec] Re: [sv-bc] explicit package exports > > > > > > > > > > > > > > > > Greg Jaxon wrote: > > > > > > > > > Well "local import Q::myInt;" seems odd if the default will be > > > > > local visibility for imports. Also "local export Q::myInt;" > seems > > > > > > > self-contradictory. > > > > > > > > I don't think that "local import" is very useful and would be fine > > > > with making it illegal. In any case, the exact rules for > > interactions > > > > > > > between "local" and "export" are certainly subject to a debate > that > > > > I'd rather leave as a separate question. > > > > > > > > "local export" would not be valid -- "export" is not a > > > > package_or_generate_item_declaration in my proposal, it is a > > > > "package_item" itself so my suggested BNF change wouldn't apply to > > the > > > > > > > package_export_declaration rule. > > > > > > > > Gord. > > > > > > > > > > > > > > > > > > Greg > > > > > > > > > > P.S. To me this argues for default public visibility (i.e. > import > > == > > > > > > > > export), > > > > > but as I understand it the committees hav already reached a > > > > compromise > > > > > to not do that. > > > > > > > > > > Gordon Vreugdenhil wrote: > > > > > > > > > >> > > > > >> > > > > >> Brad Pierce wrote: > > > > >> > > > > >>> The first option is the right way to go and doesn't look ugly > to > > > me. > > > > >> > > > > >> > > > > >> > > > > >> I should have been more careful in how I phrase that -- the > first > > > > option > > > > >> isn't ugly but I don't want to have to dig through all the > > semantic > > > > > > > >> implications on my own. The second option would be ugly. > > > > >> > > > > >> Does anyone have opinions on when "local" should NOT be > permitted > > > for > > > > >> the proposed change: > > > > >> [ local ] package_or_generate_item_declaration > > > > >> > > > > >> "local" might not make sense to me in the context of things > that > > > > might > > > > >> not have names but I'm not sure if that can happen here given > > other > > > > > > > >> semantic constraints. > > > > >> > > > > >> Gord. > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Gordon Vreugdenhil [mailto:gordonv@model.com] Stuart > > > > >>> Sutherland wrote: > > > > >>> > > > > >>> > > > > >>>> I agree that adding 'local' to package declarations is > > intuitive > > > > and > > > > >>>> makes for self-documenting code. Since it is likely that it > > will > > > > be > > > > >>>> the intent that most package items will be visible to > importers > > > of > > > > the > > > > >>> > > > > >>> > > > > >>> > > > > >>>> package, only a few, if any, items will typically need to be > > > > >>>> declared as local. If, on the other hand, the export was > used > > to > > > > > > > >>>> make package items "importable" (a new word?), then to hide a > > > small > > > > >>>> number of items > > > > >>> > > > > >>> > > > > >>> > > > > >>>> would require explicitly exporting almost all other package > > > items. > > > > >>>> > > > > >>>> I also think it makes sense to include local package items as > > > part > > > > >>>> of the export proposal. The two go hand in hand. > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> The grammar changes for allowing "local" to package > declarations > > > > might > > > > >>> be a bit ugly. There are two choices -- the easy choice is to > > add > > > > > > > >>> "local" as an optional qualifier in the package_item rule. > Ie: > > > > >>> > > > > >>> package_item ::= > > > > >>> [ local ] package_or_generate_item_declaration > > > > >>> | anonymous_program > > > > >>> | timeunits_declaration > > > > >>> > > > > >>> Then we might have to have some semantic constraints that > > "local" > > > > >>> isn't legal for some constructs but I'm not sure if that is in > > > fact > > > > the > > > > >>> case. > > > > >>> > > > > >>> The other option would be separate > > > > package_or_generate_item_declaration > > > > >>> into two parts -- one for packages and the other for > generates. > > > > >>> > > > > >>> I am willing to add the former solution and a bit of text to > > what > > > I > > > > am > > > > >>> writing up but I don't want this to snowball and I don't have > > the > > > > time > > > > >>> to try to figure out all of situations in which "local" on a > > > > >>> package_or_generate_item_declaration might not be reasonable. > > If > > > > people > > > > >>> are Ok with the simple change, fine, otherwise let's separate > > > > "local" > > > > >>> from export so that there can be more time for consideration. > > > > >>> > > > > >>> Gord. > > > > >>> > > > > >>> -- > > > > >>> > > > -------------------------------------------------------------------- > > > > >>> Gordon Vreugdenhil 503-685-0808 > > > > >>> Model Technology (Mentor Graphics) > > > gordonv@model.com > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > -- > > > > > -------------------------------------------------------------------- > > > > Gordon Vreugdenhil 503-685-0808 > > > > Model Technology (Mentor Graphics) > gordonv@model.com > > > > > >Received on Sun Sep 17 22:11:28 2006
This archive was generated by hypermail 2.1.8 : Sun Sep 17 2006 - 22:12:45 PDT