
May I suggest a third route that has the advantages of both your approaches. The backside is of course that it takes a bit of work. My suggestion is to do an effect analysis of your curry programs to identify the purely functional parts and compile them directly to pure Haskell. The rest of the programs can run in a monad. This approach should be more robust than relying on unsafePerformIO. It is also very much in the spirit of your slogan.
Thank you for the suggestion. We were thinking along the lines of identifying "the purely functional parts and compile them directly to pure Haskell" as a possibility of optimization (with some code duplication). But if the "rest of the programs can run in a monad" the question is: How much of the example program I submitted would you classify as "purely functional"? Actually, most of it is purely functional apart from the (?) - operator. But I do not see a way to make use of this. If, however, the whole program is classified as "non-functional" then this is definitely not in the spirit of the slogan. One effect we like very much about our implementation is that all expressions which do not depend on non-deterministic values are shared across the whole search. I suspect that any reasonably precise analysis will classify all the
Hi again,
On 10/17/07, Bernd Brassel
Note, that this dependence is a dynamic property. If the code of programs like the example was monadic, I do not see how not to loose this property.
I'm not quite sure what you mean when you say that dependence is dynamic.
Simon Peyton Jones said:
Adding these artificial dependencies may amount to exactly the kind of effect analysis that Josef suggests.
Yes such a determinism analysis is a good idea to optimize functional logic programs and we have already done work in that direction. But I would not like to turn those programs into a monad which we cannot prove to be deterministic. Your hint of "adding artificial dependencies" sounds more promising.
Don't take my suggestion of using monads too literally if you don't like monads. Indeed Simon's dependency injection can be formulated as a monad but you don't need to use monads if you don't want to. My point was that your programs will be divided into a pure part and an effectful part. Monads are just one way of capturing the effectfulness. Cheers, Josef