    <pre>
        mi3(true).
        mi3((A,B)) :-
                mi3(B),        % first B, than A
                mi3(A).
        mi3(g(G)) :-
                mi_clause(G, Body),
                mi3(Body).
    </pre>

    From a logical point of view, this changes nothing (conjunction is
    commutative). Procedurally, there's a difference: With minor
    adjustments to <b>mi_clause/2</b> (adding the fact
    "defaulty_better(false, false)." and guarding <i>G</i> against the
    atom <b>false/0</b>), and after adding the additional clause

    <pre>
        mi3(false) :- false.
    </pre>

    this MI can be used to prove that the query
    "?-&nbsp;declarative_false."  cannot succeed given the predicate's
    definition:

    <pre>
        declarative_false :-
                declarative_false,
                false.
    </pre>

    This can't be derived with the standard execution order.

    HERE, filler text is needed, showing that the issue may be related
    to SCROLLING.

    If I remove the preceding paragraph starting with HERE, this line,
    and everything following

    until the <br><br> in, then the issue goes away.

    Even more filler text is needed,

    and therefore additional text and a few more paragraphs appear

    between the previous snippet and the final one.

    Even more filler text is needed,

    and therefore additional text and a few more paragraphs appear

    between the previous snippet and the final one.

    <br><br>

    We can ask the user before we execute goals (<i>tracing</i>),
    print out the execution history or restrict access to safe goals
    by adjusting the third clause:

    <pre>
        mi2_safe(g(G)) :-
                (   safe_goal(G) ->
                    mi_clause(G, Body),
                    mi2_safe(Body)
                ;   throw(cannot_execute(G))
                ).
    </pre>