intermodule optimization bug

Fergus Henderson fjh at cs.mu.OZ.AU
Sun Feb 15 19:45:58 AEDT 1998


On 15-Feb-1998, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > When compiling with intermodule optimization enabled,
> > private equivalence types in imported modules are visible,
> > so previously abstract types may become concrete.
> 
> > This happens before semantic checking, so it affects whether
> > or not the compiler reports type errors.  Clearly it can
> > make type errors go away. 
> 
> This problem does not come up when using mmake, since
> the `.c' file depends on the `.opt' file for the module.
> The `.opt' file for a module is created without looking
> at the `.opt' files for other modules.

Ah yes, good point.  I'd forgotten about that.
I think that this is a quite acceptable solution to
the "too few errors" problem.

> > Less obvious is the fact that it
> > can also introduce ambiguity errors into code that would
> > otherwise be ambiguity-free. 
> 
> Maybe we should reserve a functor (it doesn't absolutely
> have to be an operator) for type qualification so that we
> can enable the code to output type qualifications for code
> in `.opt' files.

I don't think that putting type qualifications in `.opt'
files would help.  The ambiguity can arise for code in the
`.m' file being compiled, not just for code in the `.opt'
files that it imports.

In the test case which caused the problem,
polymorphism.m used '-'/2 with types foo and int,
where some module imported by polymorphism.m
had `:- type foo == int' in its implementation.
Without intermodule optimization, the type checker
resolves the ambiguity between std_util:'-' (pair)
and int:'-' (subtraction) in favour of the former,
because the latter would be a type error.
When compiling with intermodule optimization enabled,
this became a use of '-' with types int and int,
which was ambiguous.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.



More information about the developers mailing list