> On Jul 23, 2015, at 12:46 AM, Paul Richard Thomas > <paul.richard.tho...@gmail.com> wrote: > > Since all the private entities in a module have to be transmitted to > their descendant submodules, whilst keeping them hidden from normal > use statements, I have chosen to write the module file as usual and > add a second part that contains the private entities. This latter is > only read when processing submodule statements.
Hi Paul, Could you comment on whether this approach alleviates compilation cascades as seems to have been envisioned when submodules were added to the standard? My guess is that a developer could adopt a policy of putting only public information in a module and reserving all private information for submodules, which would mitigate against unnecessary compilation cascades and would be consistent with putting the interface in the module and the implementation in a submodule.. > It does cross my mind that all of this part of the submodule > implementation could be subject to the condition that a compiler > option is set. I am struck by the notion that making private module > entities available to submodules is an unnecessary complication and > that it amounts to be an error in the standard. This is why I am > suggesting the possibility of a specific compiler option. I strongly advocate against having to pass flags to force standard-compliant behavior (I happened to have just posted to c.l.f on a frustrating way in which two compilers currently require flags to comply with the standard), although it sounds like it might not matter in this case if one adopts the aforementioned policy of putting only pubic information in modules. Damian
