[m-users.] Is this a compiler bug?

[Julien Fischer]

On Tue, 15 Nov 2022, Volker Wysk wrote:

> You talk about "reordering" of the clauses, which make up the two
> superhomogenous forms. The second form, you say, could or could not be a
> reordered version of the first. But the two superhomogenous forms can't be
> reordered versions of each other, because the first one consists of three
> clauses, whereas the second one consists of two clauses. I don't fully get
> what you're saying.

What is being reordered are *goals* within a clause, not clauses
themselves. (main/2 has only a single clause in both versions of the
program.)

> I'm wondering if there's some documentation about superhomogenous forms and
> mode analysis. The word "superhomogenous" doesn't occur in the language
> reference manual.

Superhomeogenous normal form (to give its full name) is described in
many of the Mercury papers. It is the representation on which many of
the passes in the compiler operate. (See for example, section 2.2 of
"The execution algorithm of Mercuy: an efficient purely declarative
logic programming language." by Somogyi, Henderson and Conway to name
but one.)

...

> The following version of main fails to compile (like expected) with
> "Unification of `P1' and `P2' can fail". (Here we have the point of
> failure). Even though that isn't the case:
>
> main(!IO) :-
>    P1 = A - B,
>    p(P2, !IO),
>    P1 = P2.
>
> I suppose this due to what you described as "the fact that the current
> Mercury implementation does not support partial instantiation properly". 

In this case, the explanation is: the compiler has to generate an
out-of-line predicate to implement the unification of P1 and P2. That
generated predicate is declared to be semidet, which is why you are
getting the determinism error. The unification should to be det, since
filling in the holes in P1 with the args from P2 will aways succeed.
The fact that the compiler does not know that is one of the limitations
I was referring to.

> If I remember correctly, this has already been addressed at some point in
> this mailing list.

It's been addressed on this list (or the developers list) quite a few times.

Julien.