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