[m-dev.] handling of impossible insts
Andrew Bromage
bromage at cs.mu.oz.au
Thu Aug 14 13:47:14 AEST 1997
G'day.
Fergus Henderson wrote:
> I seem to remember that Andrew and/or Tom had made a change to
> mode analysis so that it checked for bound(...) insts with an
> empty list of possible insts, and set the whole instmap to unreachable
> for those cases. Apparently this has not yet been committed.
> Do you still have the patch?
I have my version of the patch which I've just updated to include the
split of inst_match and is bootchecking as I'm writing this.
While waiting for that bootcheck, one question which I'll throw open.
Consider this program (this is the test case for the patch):
<<
:- module empty_bound_inst_list.
:- interface.
:- pred p is failure.
:- implementation.
:- import_module std_util.
:- type some_functors ---> foo ; bar ; baz.
p :-
( Y = yes(bar), Z = foo
; Y = yes(baz), Z = foo
),
Y = yes(Z).
>>
Without the empty bound_inst list patch, p is classified as being
semidet. The bound_inst list patch correctly identifies the final
unification as having determinism failure.
However should p/0 be given determinism failure (with the unification
being replaced with fail by the mode checker in a manner analogous
to what we currently do with det simple_tests), or should the compiler
report a mode error?
The current compiler with the patch applied gives a mode error:
<<
empty_bound_inst_list.m:015: In clause for `p':
empty_bound_inst_list.m:015: mode error in unification of `Y' and `std_util:yes(Z)'.
empty_bound_inst_list.m:015: Variable `Y' has instantiatedness `unique(std_util:yes(unique(empty_bound_inst_list:bar ; empty_bound_inst_list:baz)))',
empty_bound_inst_list.m:015: term `std_util:yes(Z)'
empty_bound_inst_list.m:015: has instantiatedness `std_util:yes(unique(empty_bound_inst_list:foo))'.
>>
Cheers,
Andrew Bromage
More information about the developers
mailing list