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

[Mark Brown]

On Fri, Nov 18, 2022 at 4:42 AM Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Mittwoch, dem 16.11.2022 um 14:27 +1100 schrieb 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.)
>
> Sorry, my bad.
>
> > > 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.)
>
> I've downloaded that paper. Now I need to seriously study it.
>
> >
> > ...
> >
> > > 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.
>
> The question is, what does a mere user of the Mercury language need to know
> in order to understand this, and what does he need to know in order to work
> around it?

That is a good question. The knowledge and reasoning I used was
roughly as follows (this is going to take longer to type than it took
to actually happen):

1. The error message points to a unification in the first argument to
p, but unifications aren't always explicit. I'll need to think about
what unifications the compiler sees.

2. The strict sequential semantics says, "Function calls, conjunctions
and disjunctions are all executed in depth-first left-to-right order."
I know that this determines what the compiler will see before mode
analysis, namely that the "function call" of -/2 will be before the
call to p.

3. I can't see any place where the code could fail, in particular
because -/2 is the only data constructor of the pair type so it won't
fail on that account..

4. I can, however, see that the unification would construct a
partially instantiated term. Ugh, it could be a mode analyser
limitation.

5. The mode of p's first argument is out, so this unification is
probably meant to be a deconstruction that occurs after p returns.

6. If I put the unification after the call to p, the mode analyser
won't need to reorder it to get it to the right place. Maybe that will
avoid the reordering bug?

If that hadn't have worked I might have looked at the HLDS dump for
more clues (or I might have done that in order to explain it to
someone, as Julien did above).

So to answer your question, I think step 2 was probably the obscure
one (that process is part of what is done in the conversion to
superhomogeneous form).

Hope that helps!

Mark

>
> Cheers,
> Volker
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users