<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Thank you, Zoltan and Julien! <div class="moz-cite-prefix">On 29-10-2020 04:17, Zoltan Somogyi wrote: </div> <blockquote type="cite" cite="mid:E1kXyRQ-0006v3-72@rmmprod07.runbox"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">2020-10-29 13:49 GMT+11:00 "Julien Fischer" <a class="moz-txt-link-rfc2396E" href="mailto:jfischer@opturion.com"><jfischer@opturion.com></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> </blockquote> <pre class="moz-quote-pre" wrap=""> Agreed.</pre> </blockquote> Very interesting. I indeed got the experience from introductory Prolog texts (most notably Markus Triska's "The Power of Prolog") 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> ) 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. Could you elaborate on this? ---- A related question is about higher-order predicates/functions, such as `list.map`: 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 immediately encountered 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). (C.f. the reference manual, 8.1) Is this an implementation limitation that might be lifted some time in the future? Or is this an inherent limitation of logic-based type checking? (Would type-checking become undecidable if multiple modes are allowed?) Or maybe I am simply doing something wrong? Thank you, ~Marten/Qqwy </body> </html>