[m-users.] Functions vs Predicates?

Qqwy/Wiebe-Marten qqwy at gmx.com
Sat Oct 31 04:01:25 AEDT 2020

Thank you, Zoltan and Julien!

On 29-10-2020 04:17, Zoltan Somogyi wrote:
>> 2020-10-29 13:49 GMT+11:00 "Julien Fischer" <jfischer at opturion.com>:
>> 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.
> Agreed.
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. https://www.metalevel.at/prolog/purity )/
/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

I tried to translate a Prolog Sudoku-solver/generator/tester (c.f.
http://rosettacode.org/wiki/Sudoku#Prolog) to Mercuy, and immediately
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,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20201030/3fc00335/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mercurylang.org/archives/users/attachments/20201030/3fc00335/attachment.sig>

More information about the users mailing list