TREE_PUBLIC for module symbols?

[Damian Rouson]

> On Jul 1, 2015, at 11:51 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> 
> Hi Damian,
> 
> There is a double problem:
> 
> (i) Since entities in submodules have to behave as if they are host
> associated to the module, it means that all entities in the module
> have to be visible. I have chosen to implement this by having two
> parts to the module file; the first is the normal part, such that
> other program units than submodules can use the module as usual. The
> second part contains everything else and is only read by submodules.
> This has the advantage of minimizing the changes. However, it means
> that the potentially IPR sensitive part of the module is visible by
> gunzipping the module file.

How about creating a new file containing the private details that only submodules need?   I recognize it might not be desirable to add a new file, but presumably we’re already going to have some new files (.smod or some such) anyway so why not add one more?  Otherwise, there could be a lot of disappointed users if submodules don’t accomplished their advertised purpose.   I think the cascade issue featured prominently when submodules were added to the language.  See section 0.1.2 of ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650/N1602.pdf.

Possibly the generation of the .modpriv file could be triggered by a compile-time flag.  The default behavior would be to store the information in the .mod file, which improves runtime performance by facilitating optimization.  A user would have the option, however, to choose compile-time performance over runtime performance by setting the flag depending on which is more important in their application or their current workflow.  I would choose compile-time performance on a large project under development.  Then I would choose runtime performance when producing binaries for release.   


Damian