What is the state of the art in encapsulated search in functional logic programming?

Question

I am particularly interested in solutions to the problem that encapsulated search can depend on the order of evaluation.

According to [1], encapsulated search in PAKCS depends on the order of evaluation, while in MCC, it does not, but using it requires knowledge of the compiler implementation and it does not follow the Curry language specification. This was written in 2007, so it may of course be out of date now.

KiCS2 returns results from encapsulated search in the IO monad, but I do not understand why.

[1] Braßel and Huch, On a Tighter Integration of Functional and Logic Programming, Proc. APLAS 2007

Answer 1

The reasons for using the IO monad appear to be described in Braßel and Huch and Hanus, 2004, but I cannot find a clear reason given for using a list instead of a set. I guess it is so the list can be elaborated lazily.

It seems that the approach described in the 2007 paper was unsatisfactory for some reason (I don't know why), because KiCS2 has gone back to the "API" described in the 2004 paper, i.e. using the IO monad. (There is an unsafe version which does not use the IO monad, but that is not referentially transparent!)

• Erik Kaplun: as to list-vs-set, I believe they've mentioned they sometimes return multisets.

Answer 2

See http://www-ps.informatik.uni-kiel.de/kics2/lib/Findall.html: it says IO based approach is deprecated and the prefferred way not is Curry's SetFunctions module, This new design does away with IO-wrapped return values and has other means to avoid leaking indeterminism and referential non-transparency into the pure-FP land.

• Raphael: I removed a discussion about how to properly cite resources here. Let us continue in chat, which is the more appropriate platform.