Quel est l'état de l'art de la recherche encapsulée dans la programmation logique fonctionnelle?

Je suis particulièrement intéressé par les solutions au problème que la recherche encapsulée peut dépendre de l'ordre d'évaluation.

Selon [1], la recherche encapsulée dans PAKCS dépend de l'ordre d'évaluation, tandis que dans MCC, elle ne le fait pas, mais son utilisation nécessite la connaissance de l'implémentation du compilateur et elle ne suit pas la spécification du langage Curry. Cela a été écrit en 2007, il est donc possible que ce soit obsolète maintenant.

KiCS2 renvoie les résultats de la recherche encapsulée dans la monade IO, mais je ne comprends pas pourquoi.

[1] Braßel et Huch, Sur une intégration plus étroite de la programmation fonctionnelle et logique , Proc. APLAS 2007

Les raisons de l'utilisation de la monade IO semblent être décrites dans Braßel et Huch et Hanus, 2004, mais je ne trouve pas de raison claire donnée pour utiliser une liste au lieu d'un ensemble. Je suppose que c'est ainsi que la liste peut être élaborée paresseusement.

Il semble que l'approche décrite dans le document de 2007 n'était pas satisfaisante pour une raison quelconque (je ne sais pas pourquoi), car KiCS2 est revenu à l '"API" décrite dans le document de 2004, c'est-à-dire en utilisant la monade IO. (Il existe une version dangereuse qui n'utilise pas la monade IO, mais qui n'est pas référentiellement transparente!)

Voir http://www-ps.informatik.uni-kiel.de/kics2/lib/Findall.html : il indique que l' IOapproche basée est déconseillée et que la manière préférée n'est pas le SetFunctionsmodule de Curry , cette nouvelle conception supprime les IOvaleurs de retour encapsulées et dispose d'autres moyens pour éviter les fuites d'indéterminisme et de non-transparence référentielle dans la terre pure-FP.