Prevent optimization from tempering with unsafePerformIO

[Josef Svenningsson]

Hi again,

On 10/17/07, Bernd Brassel <bbr at informatik.uni-kiel.de> wrote:
> > 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
pure functions in your example program as pure, i.e. ifThenElse,
(|||), depthFirstSearch, dfs and choose. But which functions that will
be classified as pure of course depends on the exact formulation of
the analysis. Also, I could be wrong since I'm not 100% sure of the
intended semantics of your examples.

Some people who've looked into determinism analysis in detail is
Ricardo Peña and Clara Segura, when working with the language Eden.
You can find most of the relevant papers here:
http://dalila.sip.ucm.es/miembros/clara/publications.html

> 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