AW: [Bug fortran/52846] [F2008] Support submodules - part 3/3

[Bader, Reinhold]

Hello Paul, 

To my knowledge, the J3 interp F08/128 was triggered by a question coming from Bill Long from Cray. 
The interp's text was written by the Fortran standard's editor. So there is no direct relation to this thread.

F08/0142 (useless submodules) was in turn triggered by the example given for F08/128, by Daniel Chen from IBM.
And indeed this seems to have caused some grief to other implementors.

Cheers
Reinhold

> -----Ursprüngliche Nachricht-----
> Von: Paul Richard Thomas [mailto:paul.richard.thomas@gmail.com]
> Gesendet: Dienstag, 11. August 2015 12:28
> An: Bader, Reinhold <Reinhold.Bader@lrz.de>
> Cc: Toon Moene <toon@moene.org>; Mikael Morin <mikael.morin@sfr.fr>;
> Damian Rouson <damian@sourceryinstitute.org>; fortran@gcc.gnu.org; gcc-
> patches <gcc-patches@gcc.gnu.org>; salvatore.filippone@uniroma2.it
> Betreff: Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3
> 
> Dear All,
> 
> Has this been occasioned by this thread or have other makes encountered the
> same difficulty in implementation?
> 
> Cheers
> 
> Paul
> 
> On 10 August 2015 at 20:57, Bader, Reinhold <Reinhold.Bader@lrz.de> wrote:
> > Hello Toon, all else,
> >
> > a bit unfortunate, in my opinion (I was present at the discussion).
> > I've in the meantime taken some effort to implement what the design
> > pattern experts might call an "abstract factory with full dependency
> > inversion" as a bare-bones framework and have attached an archive with three
> variants:
> >
> > * pre_interp contains the code that is presently valid (and indeed compiles fine
> >    with both gfortran and ifort), but would become invalid due to indirect
> >    parent module access
> > * post_interp contains a variant that uses a helper module (mod_glue) to avoid
> >    the indirect ancestor use access (if there is a more concise way to do this,
> >    I'd like to know ... up to now this is the best I can do)
> > * post_interp_v2 another shorter variant that pushes the extension types into
> a submodule
> >    (with the disadvantage that these types are not really reusable, and
> >     that the monster module problem is shifted to a monster submodule, or a
> chain of
> >     submodules)
> > You may need to edit the Makefiles to build.
> >
> > I would of course like to know how people feel about reintroducing
> > this restriction, especially since the only reason given was that
> > ancestor module access and its use association overriding host
> > association would confuse users ... which is a problem which in my
> > opinion could have been dealt with in a slightly different manner
> > without removing the  permission for indirect parent
> > module-referencing use statements. It is not clear to me whether
> *implementations* other than gfortran have problems with this, though.
> >
> > More germane to this thread's discussion actually is another interp
> > that was also passed, and which appears entirely uncontroversial:
> > http://j3-fortran.org/doc/meeting/207/15-209.txt
> > It seems to me that this would permit avoiding generation of the .smod
> > files for modules that do not specify an separate module procedure interface.
> >
> > Cheers
> > Reinhold
> >
> >> -----Ursprüngliche Nachricht-----
> >>
> >> Although I do not immediately know if this is relevant for *this*
> >> debate, J3 passed the following (attached) interpretation on
> >> submodules the past week (it still has to go to several mail ballots,
> >> but still), overwhelmingly prefering option 3:
> >>
> >> [attached]
> >>
> >> Kind regards,
> >>
> >> --
> >> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
> >> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands At home:
> >> http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress
> >> of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
> 
> 
> 
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to
> read.
> 
> Groucho Marx