Dear Mikael, It had crossed my mind also that a .mod and a .smod file could be written. Normally, the .smod files are produced by the submodules themselves, so that their descendants can pick up the symbols that they generate. There is no reason at all why this could not be implemented; early on in the development I did just this, although I think that it would now be easier to modify this patch.
One huge advantage of proceeding in this way is that any resulting library can be distributed with the .mod file alone so that the private entities are never exposed. The penalty is that a second file is output. With best regards Paul On 23 July 2015 at 17:42, Mikael Morin <mikael.mo...@sfr.fr> wrote: > Hello Paul, > > Le 23/07/2015 09:46, Paul Richard Thomas a écrit : >> >> 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. >> > why not write them to the/a .smod file? It was its primary purpose, wasn't > it? > [Sorry, I followed the submodule stuff very remotely]. > > It's probably bad practice to put private entities in module files, at least > now that submodules are supported. Nevertheless with your change, > modifications made to private entities produce recompilation cascades, even > though the public interfaces are left unchanged. > > Mikael -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
