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.tho...@gmail.com] > Gesendet: Dienstag, 11. August 2015 12:28 > An: Bader, Reinhold <reinhold.ba...@lrz.de> > Cc: Toon Moene <t...@moene.org>; Mikael Morin <mikael.mo...@sfr.fr>; > Damian Rouson <dam...@sourceryinstitute.org>; fort...@gcc.gnu.org; gcc- > patches <gcc-patches@gcc.gnu.org>; salvatore.filipp...@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.ba...@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: t...@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
