RE: [sv-ec] Re: [sv-bc] explicit package exports

Since we're revisiting some aspects of packages. I'd like to bring up
something that I've wanted to add to the import (and now export)
mechanism for some time: The ability to import *all* identifiers in a
package without having to explicitly name every identifier either as an
explicit import or in combination with a wildcard import.

Specifically, allow the syntactical from (currently illegal):
	export package_name ; 
to designate that every identifier in package_name be imported into the
importing scope. Semantically, this is identical to something like:
	foreach identifier S in package_name begin
		import package_name::S;

This import mechanism IMHO would solve one pf the problems with the
existing wildcard imports: that sometimes users may unwittingly *not*
import the "correct" identifier because their code contains a
declaration that blocks the import. This new mechanism would increase
the likelihood of name clashes, but it would reduce the uncertainty.
Personally, I prefer an explicit error to a potential problem that goes
unnoticed, and can be very hard to debug. I also believe that If we had
this import mechanism, some of the awkwardness and lack of symmetry of
the export will go away.

	Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Friday, September 15, 2006 6:53 AM
To: Bresticker, Shalom
Cc: sv-bc@eda-stds.org; SV_EC List; sv-ac@verilog.org
Subject: Re: [sv-ec] Re: [sv-bc] explicit package exports



Bresticker, Shalom wrote:
> 'local import' could be useful together with 'export *::*' as a way to
> say, 'export everything except a particular imported item'.

That is the straightforward part.  I am worried about the
semantics for combinations of export with, say, an import
*within* a local function.  Some care about edge cases will
be needed.

> A separate question: since wildcard exports as proposed would only
> export items actually imported and not import candidates, how could I
> export all of p1 to p3 via p2? I would think that could be useful.

There is no mechanism for that other than specific named re-exports.
That tends to be a bit more dangerous as a practice due to possible
name conflicts downstream, although I agree that one can have
reasonable cases for wanting this.

The current wildcard export is tailored  to match the interpretation
that
Synopsys has for "import"  and, hopefully, will help build consensus.  I
don't particularly like the semantics due to the interaction of package
implementation aspects (bodies of tasks/functions, etc) and would
personally
suggest that users only use the explictly named export form.  But at
least now we have a proposal for mechanisms that can express both.

Gord.

> Finally, when I read 19.2 in 1800-2005, I think the language and the
> examples clearly imply that import chaining was not intended. Possibly
> nobody even thought about it till now. Other interpretations of the
text
> are basically based on the argument that the text does not explicitly
> say it does not happen. I don't accept that argument. In my opinion,
the
> total lack of reference to it means the reverse.
> 
> Shalom
> 
> 
>>-----Original Message-----
>>From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> 
> On
> 
>>Behalf Of Gordon Vreugdenhil
>>Sent: Friday, September 15, 2006 12:46 AM
>>To: Greg Jaxon
>>Cc: Brad Pierce; sv-bc@server.eda-stds.org; SV_EC List; sv-
>>ac@server.verilog.org
>>Subject: [sv-ec] Re: [sv-bc] explicit package exports
>>
>>
>>
>>Greg Jaxon wrote:
>>
>>
>>>Well  "local import Q::myInt;"  seems odd if the default will be
>>>local visibility for imports.  Also "local export Q::myInt;" seems
>>>self-contradictory.
>>
>>I don't think that "local import" is very useful and would be
>>fine with making it illegal.  In any case, the exact rules
>>for interactions between "local" and "export" are certainly
>>subject to a debate that I'd rather leave as a separate question.
>>
>>"local export" would not be valid -- "export" is not a
>>package_or_generate_item_declaration in my proposal, it
>>is a "package_item" itself so my suggested BNF change
>>wouldn't apply to the package_export_declaration rule.
>>
>>Gord.
>>
>>
>>
>>>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
> 
>>>>>
>>--
>>--------------------------------------------------------------------
>>Gordon Vreugdenhil                                503-685-0808
>>Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com