[m-rev.] for review: fix handling of transitive module imports

[Simon Taylor]

On Wed, May 02, 2001 at 07:30:14PM +1000, Fergus Henderson wrote:
> On 02-May-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > 
> > Fix a bug in the module import mechanism -- use_module should
> > not be transitive. This change is needed for smart recompilation
> > to avoid needing to check whether the removal of a transitive
> > import could cause compilation errors -- it never should.
> 
> You should add something like
> 
>     Also some bugs in the handling of type classes.

Done.

> > Index: NEWS
> > ===================================================================
> > +Changes to the Mercury implementation:
> > +* We've fixed a bug in the handling of module imports. Previously,
> > +  if `module1' imported `module2' which imported `module3' in
> > +  its interface section, types, insts, modes and typeclasses defined
> > +  in the interface of `module3' could be used in `module1' even
> > +  if `module1' did not import `module3' directly.
> 
> I suggest a couple of minor changes:
> s/fix a bug/fixed a long-standing bug/
> s/types, insts/then any types, insts/

Done.

> > Index: compiler/module_qual.m
> > ===================================================================
> >  	% so we use a simpler data type here than hlds_pred__import_status.
> >  :- type import_status
> >  	--->	exported
> > -	;	not_exported.
> > +	;	not_exported
> > +	;	imported.
> 
> Hmm, if `not_exported' doesn't include the `imported' cases,
> wouldn't it be better to rename `no_exported' as `local'?

Done.
 
> > Index: compiler/prog_data.m
> > @@ -866,6 +870,13 @@
> >  		% This is used internally by the compiler,
> >  		% to identify items which originally
> >  		% came from a .opt file.
> > +	;	transitively_imported
> > +		% This is used internally by the compiler,
> > +		% to identify items which originally
> > +		% came from a .opt file.
> > +		% came from a `.opt' or `.int2' file.
> > +		% These should not be allowed to
> > +		% match items in the current module.
> 
> You should document here that unlike `:- interface', `:- implementation',
> or the other pseudo-declarations `:- imported(interface)', etc.,
> this does not define a new section of the module which lasts until
> the next pseudo-declaration.  Instead, everything which follows
> a `transitively_imported' marker is treated as transitively imported,
> regardless of what other pseudo-declarations follow.

--- prog_data.m	2001/05/02 16:30:21	1.1
+++ prog_data.m	2001/05/02 16:40:16
@@ -873,10 +873,14 @@
 	;	transitively_imported
 		% This is used internally by the compiler,
 		% to identify items which originally
-		% came from a .opt file.
 		% came from a `.opt' or `.int2' file.
 		% These should not be allowed to
 		% match items in the current module.
+		% Note that unlike `:- interface', `:- implementation'
+		% and the other pseudo-declarations `:- imported(interface)',
+		% etc., a `:- transitively_imported' declaration
+		% applies to all of the following items in the list,
+		% not just up to the next pseudo-declaration. 
 
 	;	external(sym_name_specifier)
 
> Incidentally, why is that?  It would be more consistent with the
> way that the rest of the module import stuff works for
> `transitively_imported' to define a new section.
> It would be nicer if we could keep things consistent.

Unlike the other pseudo-declarations, `:- transitively_imported' is
only for use by module_qual.m, and is ignored by everything else.
module_qual.m already makes assumptions about the order of the
items in the list (all local items come first). I'll leave it as it is.

Simon.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------