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

[Volker Wysk]

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?

Cheers,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20221117/9df3a722/attachment.sig>