RE: [sv-bc] explicit package exports

Then a footnote could be added saying that in a package_item it shall be
illegal for a package_import_declaration or package_export_declaration
to use the local keyword.

I was only responding to the mechanics of the BNF writing, not to the
language design choices they implement.

The proposal is still a work in progress.  In my experience Gord, like
the committee as a whole, is strongly motivated to make the SV language
as good as can be and always sincerely interested in hearing all
feedback.

But, when you say that 'this argues for default public visibility', I'm
confused about what   'this' refers to.

Also, couldn't a user already get this behavior with the proposed
"export *::*" statement?

-- Brad

-----Original Message-----
From: Greg Jaxon [mailto:Jaxon@synopsys.COM] 
Sent: Thursday, September 14, 2006 12:32 PM
To: Gordon Vreugdenhil
Cc: Brad Pierce; sv-bc@eda-stds.org; SV_EC List; sv-ac@verilog.org
Subject: Re: [sv-bc] explicit package exports

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
>>
>>
>