Gordon, Can you clarify one aspect of this design that differs from my first guess as to how "export" would work? I imagined that export would be identical to "import" with the only difference being the visibility of items which it addressed. But reading the proposal, I get the impression that package Pn; export Pn_1::x; endpackage; would /not/ import Pn_1::x and then re-export it. I can't think of any good reason to give an error for this case, and I think having export implicitly import takes some awkwardness out of examples such as package p5; import p4::*; export p1::x; // p1::x is visible since it is exported // from p4. ... I can sympathize that using the keyword export to also mean import is an unusual enlargement of its natural language meaning. But seeing examples where every import is duplicated as an export reminds me of Verilog 95 port declarations, with the way they add one modifier at a time - not particularly succinct. Greg Gordon Vreugdenhil wrote: > I just caught a minor BNF bug in the proposal -- I missed the > vertical bar when I added the "export *::*;" rule. I fixed > the typo and uploaded the modified version. > > Gord. > > > Gordon Vreugdenhil wrote: > >> I've uploaded an initial cut at the export proposal and >> attached it to Mantis 1323 as a placeholder. >> http://www.verilog.org/svdb/bug_view_page.php?bug_id=0001323 >> See the attached package_exports.htm. >> >> I think that I've managed to incorporate all the changes >> suggested from within the sub-group. If anyone sees errors >> or omissions, please let me know. >> >> I have not yet included the "local" declaration change since >> I need to hear some feedback as to whether there need to >> be semantic restrictions on the general case. >> >> Gord. >Received on Thu Sep 14 20:30:28 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 14 2006 - 20:30:45 PDT