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
examples.tgz
Description: examples.tgz
