Wie ist der Stand der Technik bei der gekapselten Suche in der funktionalen Logikprogrammierung?

Ich bin besonders an Lösungen für das Problem interessiert, dass die gekapselte Suche von der Reihenfolge der Bewertung abhängen kann.

Laut [1] hängt die gekapselte Suche in PAKCS von der Reihenfolge der Auswertung ab, während dies in MCC nicht der Fall ist. Die Verwendung erfordert jedoch Kenntnisse über die Compiler-Implementierung und folgt nicht der Curry-Sprachspezifikation. Dies wurde 2007 geschrieben, daher kann es jetzt natürlich veraltet sein.

KiCS2 gibt Ergebnisse der gekapselten Suche in der E / A-Monade zurück, aber ich verstehe nicht warum.

[1] Braßel und Huch, Über eine engere Integration von funktionaler und logischer Programmierung , Proc. APLAS 2007

Die Gründe für die Verwendung der IO-Monade scheinen in Braßel und Huch und Hanus, 2004, beschrieben zu sein, aber ich kann keinen klaren Grund für die Verwendung einer Liste anstelle eines Satzes finden. Ich denke, es ist so, dass die Liste träge ausgearbeitet werden kann.

Es scheint, dass der in der Veröffentlichung von 2007 beschriebene Ansatz aus irgendeinem Grund unbefriedigend war (ich weiß nicht warum), da KiCS2 zu der in der Veröffentlichung von 2004 beschriebenen "API" zurückgekehrt ist, dh die IO-Monade verwendet. (Es gibt eine unsichere Version, die die E / A-Monade nicht verwendet, aber nicht referenziell transparent ist!)

Siehe http://www-ps.informatik.uni-kiel.de/kics2/lib/Findall.html : Es heißt, dass der IObasierte Ansatz veraltet ist und der bevorzugte Weg nicht Currys SetFunctionsModul ist. Dieses neue Design IObeseitigt -umhüllte Rückgabewerte und hat andere Mittel, um zu vermeiden, dass Indeterminismus und referenzielle Nichttransparenz in das reine FP-Land gelangen.