<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Thank you, Zoltan and Julien!<br>
<div class="moz-cite-prefix">On 29-10-2020 04:17, Zoltan Somogyi
<pre class="moz-quote-pre" wrap="">2020-10-29 13:49 GMT+11:00 "Julien Fischer" <a class="moz-txt-link-rfc2396E" href="mailto:email@example.com"><firstname.lastname@example.org></a>:
That said: I would argue that it is easiser to comprehend the intent
of code using the former two names and that such code is unlikely to
be usefully reversible anyway.
Aside: I find that most introductory logic programming / Prolog texts tend
to overrate the importance of being able to make operations reversible;
it's a cute trick but of very limited utility in non-trivial programs.
<pre class="moz-quote-pre" wrap="">
Very interesting. <br>
I indeed got the experience from introductory Prolog texts (most
notably Markus Triska's "The Power of Prolog") <br>
that creating predicates which retain as much "logical purity" as
possible are beneficial to keep your code flexible and thus testable
and maintainable. (c.f. <a class="moz-txt-link-freetext" href="https://www.metalevel.at/prolog/purity">https://www.metalevel.at/prolog/purity</a> )<i><br>
</i>Of course, whether this sentiment is (a) shared by more
experienced Prolog developers, and (b) can be applied 1:1 to Mercury
are things I do not know.
<p>Could you elaborate on this?</p>
<p>A related question is about higher-order predicates/functions,
such as `list.map`:</p>
<p>I tried to translate a Prolog Sudoku-solver/generator/tester
(c.f. <a class="moz-txt-link-freetext" href="http://rosettacode.org/wiki/Sudoku#Prolog">http://rosettacode.org/wiki/Sudoku#Prolog</a>) to Mercuy, and
the problem that higher-order predicates/functions such as
`list.map` seemingly can only be used in a single mode at a time,
since the predicate/function you pass to it needs to have only a
single mode (if it has multiple you need to wrap it in a lambda
expression that exposes only one of them).<br>
(C.f. the reference manual, 8.1)<br>
Is this an implementation limitation that might be lifted some time
in the future? <br>
Or is this an inherent limitation of logic-based type checking?
(Would type-checking become undecidable if multiple modes are
Or maybe I am simply doing something wrong?