for review: add nested modules [5/5]

[Peter Schachte]

On Wed, 4 Mar 1998, Fergus Henderson wrote:

> It's pronounced "a colon-dash implementation declaration".

Grumble...  Perhaps by some readers....

> > >  If a module wishes to make use of entities exported by other modules,
> > >  then it must explicitly import those modules using one or more 
> > > - at code{import_module} or @code{use_module} declarations.
> > > + at samp{:- import_module @var{Modules}} or @samp{:- use_module @var{Modules}}
> > > +declarations.  In both cases, @var{Modules} is a comma-separated list of
> > > +(fully-qualified) module names.
> > 
> > I don't think you mean fully-qualified.  Will you have to write
> > 
> > 	:- import_module :std:list.
> > 
> > to import the list module?
> 
> If/when we add support for a leading ":" in module names,
> then we should revisit the use of the term "fully-qualified" here.

Alright, will you have to write

     :- import_module std:list.

to import the list module?  That's what you're saying.  It's also
inconsistent:  you don't have to fully qualify anthing else in a module you
import.

> > > +The mapping between module names and source file names is
> > > +implementation-defined.  (The University of Melbourne Mercury
> > > +implementation requires a module named @samp{foo:bar:baz} to be
> > > +located in source file @file{foo.bar.baz.m}.)
> > 
> > This is going to bite you someday, whether due to filename length
> > limits on some unices, or braindead DOS 8.3 restrictions, or limits on
> > the number of `.' characters in a file name. 
> 
> Implementations on OSs which don't support such file names
> can use different file naming conventions, or can (for example)
> allow the user to provide a file containing the mapping between
> module names and source files.

And at that time you can consider yourself bitten.  Actually it's not so
much you that will be bitten as the poor saps who have to contend with
porting Mercury code to such a machine.  This bug bite (well, misfeature
bite) could be avoided if users fully qualify separate submodule names. 

> > And, as I argued before,
> > a switch in the Mmakefile isn't the right place for this information,
> > either.
> 
> if the user can't easily
> figure out a module's fully-qualified name when reading it, then
> he can't tell which parent modules it implicitly imports.
> But that's a separate issue.

That's the issue I'm raising.

> > So a module must both include and use a separate submodule in order to
> > have access to its contents?
> 
> Yep.

Why?  This seems rather a nuissance, since there's not much point in having
a submodule you can't use. 

So does this mean then that a module can have contents that it exports but
doesn't itself have access to?  That's a new feature.

Until now a module always had access to all the "contents" of everthing
inside itself. Submodules should have you a way to hide private things, but
I don't see why they should even hide public things from their parent
(especially since the parent so generously shares all its contents with
them).


-Peter Schachte			| One never notices what has been done; one
pets at cs.mu.OZ.AU		| can only see what remains to be done.
http://www.cs.mu.oz.au/~pets/	| -- Marie Curie 
PGP key available on request	|