RE: [sv-bc] explicit package exports

Greg and Surrendra,

I think you are confusing visibility with exporting a symbol.

All identifiers are public by default. (Available for importation). This
is separate from exportation.

As we discussed in the sv-bc meeting, export would change the way an
import works. It means that a symbol will get exported to the symbol
table of the package doing the import, i.e. allow chaining.

Dave




> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Surrendra Dudani
> Sent: Thursday, September 14, 2006 12:53 PM
> To: sv-bc@server.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
> >>
> >>
> >
>