Prevent optimization from tempering with unsafePerformIO

[Bernd Brassel]

Hi Stefan!

Thanks for your answer.

Stefan O'Rear wrote:
> Might I suggest, that the problem is your use of unsafePerformIO?  

Yes you might. And you are surely right. But not using it in this way is
not an alternative.

> why do you want to do this unsafely,
> instead of just using 'length'?  unsafePerformIO is a very slow
> function, remember)

The big picture is that we generate programs like this example in order
to compile the functional logic language Curry down to Haskell.
Basically, there are two ways to do this:

a) write an interpreter for Curry in Haskell, e.g., by employing
non-determinism monads
b) extend Haskell by employing side effects

Alternative a) is not really an issue for us. Doing it this way, all
Curry programs will suffer in performance in such a magnitude that - in
comparison - unsafePerformIO is super-fast. In addition, we already have
interpreters for Curry which I do not assume a Haskell interpreter to
outperform without 5 years worth of tuning.

Alternative b) is the choice, because doing it this way, all
deterministic, i.e., purely functional parts of Curry programs would
take advantage of Haskell being a functional language. If then the logic
parts are not so fast, e.g., because unsafePerformIO is slow, this does
not matter so much. In comparison to other approaches (like Alternative
a) and many other implementations of Curry) our slogan is: "make
functions fast and logic possible". Fast functions will outweigh the
slowdown for logics. But to get "functions fast" employing optimization
sounds like a good idea to me. But even without any optimization, our
system can compare well to most other implementations for many
applications.

Thanks for your input!

Bernd