Re: [sv-bc] Questions on export statement

I've reread the import/export draft standard.  It is stated almost clearly enough;
but I still share some of Surya's confusion.  LRM section 26.6 says:

> [1] An export of the form package_name::name makes the given declaration available.
> [2] It shall be an error if the given declaration is not a candidate for import or
>     if the declaration is not actually imported in the package.
> [3] The declaration being exported shall be imported from the
>     same package_name used in the export.
> [4] If the declaration is an unreferenced candidate for import, the export
>     shall be considered to be a reference and
>     shall import the declaration into the package following
>       the _same_ rules as for a direct import of the name.

The third sentence sounds like it enforces a sanity check: "Make sure
I'm exporting the definition I that is provided by a specific package_name."
I have no complaint with that intention, but I find the sentence hard to
comprehend, too restrictive, and it forces redundant declaration syntax.

A package P1 could hold a definition which originates in P2 without having
directly imported using the name P2.  That is one of the benefits of this
"chaining" idea, a package P3 can provide an API (to P1) built out of other package
content (P2 in this case).  Note that P1 is also free to import P2::*;
so here's my question:

package P3;
  import P2::x;
  export P2::x;
endpackage

package P1;
  import P3::x;
  export P2::x;
  ...

   At the point where P1 says "export P2::x;", the "x" in P1's global scope is
the P2::x that was provided by "import P3::x;".  Is P1 obliged to /also/ write
either "import P2::x;" or "import P2::*;" ?

  I admit that by omitting the direct import, P1 is claiming to
know details of P3's implementation.  That may or may not be best practice.
Surely he could have said "export P3::x" and maybe it's all just a typo.
But no functional error has been committed; we have an x; it came from P2...
Is this sentence trying to establish a "Know Thy Exports" commandment?

   If P1 is obliged to add this redundant syntax, what purpose does that serve?
Adding a direct import means that package P2 must also be in attendance during
the compilation of P1.  Merely having a copy of P2::x inside P3 is no longer enough.
But maybe that is what it ought to take to properly serve P1's request that the x it got
(from wherever) should be exported provided it matches the x that is exported
from P2.  I'd like to know if "Export Certification" is one of LRM's intended features.

   I would prefer if the "declaration" syntax for the chaining feature
was purely declarative and had the combined effect of "import_and_export".
Packing both into the keyword "export" is a bit rough, but
I'd like to somehow remove this redundancy, and also the silly exception to
the scope-extraction meaning of the syntax "P::x". ...  Notice how the
second sentence in the above LRM quote almost contradicts the fourth in:

package p2;
   import p1::*;
   export p1::x;
endpackage

  Although p1::x /is/ a candidate for import, it hasn't been "actually imported" yet
when we hit the export statement.  Seems like an error by sentence two.  It takes
the fourth sentence to make an exception and to specially define that p1::x in an
export statement is /not/ an ordinary extraction reference (which "extracts", but doesn't
"import" x), but here is a new form of reference that can trigger wildcard import!  I find
that concept confusing, and it gets more so when we return to my earlier example and write

package P1;
  import P2::*;
  import P3::*;
  export P2::x;
endpackage

If P3 contains an x which is different from P2::x, will the "wildcard import" P2::x fail?
What will the error be: "The symbol 'x' is undefined in P1"?   Or does it declare x in
P1 as being the one that was declared in P2, the way an "import" statement would?

  I'd rather see either of the following ways used to accomplish this purpose:

package p2;
   import export p1::x;
endpackage

or

package p2;
   import export p1::*;
   function y();  y=x(42); endfunction
endpackage

I.e., ditch "export" as a declaration statement and just use it as some kind of
modifier in the list of package items of an import statement.

As always, this may be asking too much too late in the approval process.
But, of course, the syntax I just suggested is an "extension".  And in the
context of such a feature development, I'd like to hear more about the idea
behind the "Know Thy Exports" commandment.

Greg

Disclaimer: I float these ideas for committee discussion, and not as a
voting position of my employer, nor as a specification for any present or future
products from my employer.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.