This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3
- From: Damian Rouson <damian at sourceryinstitute dot org>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: "Bader, Reinhold" <Reinhold dot Bader at lrz dot de>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Salvatore Filippone <salvatore dot filippone at uniroma2 dot it>
- Date: Thu, 23 Jul 2015 01:22:31 -0700
- Subject: Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3
- Authentication-results: sourceware.org; auth=none
- References: <CAGkQGiJ-HQA97YRC0fSjR4KFxS=7ft8ci6YjYyO7AWGi_md+cw at mail dot gmail dot com>
> On Jul 23, 2015, at 12:46 AM, Paul Richard Thomas <paul.richard.thomas@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