Well "local import Q::myInt;" seems odd if the default will be local visibility for imports. Also "local export Q::myInt;" seems self-contradictory. 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 >> >> >Received on Thu Sep 14 12:31:52 2006
This archive was generated by hypermail 2.1.8 : Thu Sep 14 2006 - 12:33:04 PDT