Re: [sv-bc] explicit package exports

Surrendra,

I tend to agree, but, on the other hand, one could still get full
package chaining under Gord's proposal by using "export *::*".

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Surrendra Dudani
Sent: Thursday, September 14, 2006 12:53 PM
To: sv-bc@verilog.org
Subject: RE: [sv-bc] explicit package exports

It makes sense to have public visibility by default, and optionally,
restrict it by using local, such as local import Q::myInt;

There would be no need for export.

Surrendra 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
Sent: Thursday, September 14, 2006 3: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
>>
>>
>