[tsimionescu]

Because as code evolves you may find you need some logging in pureFun and now you have to go and sprinkle some IO wherever pureFun is used, which may propagate to who knows how many other places.

Of course, I suppose there is always unsafePerformIO, at least for those late-night debug sessions.

[nybble41]

> Of course, I suppose there is always unsafePerformIO, at least for those late-night debug sessions.

For temporary debug output you should probably consider the Debug.Trace module before unsafePerformIO. It has a simpler interface and doesn't introduce the possibility of arbitrary I/O, just text output (and event logging if that's enabled in the RTS).

[implicit]

This happens less often than you might expect.

If you're able to run the code locally, there is a function called Debug.Trace.trace which writes messages to stdout without requiring IO.

If it's a production issue, all you need to do is figure out what is being passed to your function. It's a pure function, so you can always debug it locally once you've got that.

[verttii]

Why would I need logging inside a pure function?

[tsimionescu]

Because you suspect that it has a bug and need to see intermediate outputs to verify.

[verttii]

Haskell doesn't work that way at all. If you have variables inside a function, due to laziness their values may or may not ever be computed. Moreover, Haskell compiler sort of reduces the equations so the functions are not imperative and the computations would not happen as you expect them to. Logging would not get you anywhere.

However, you can just log the output if you like without putting IO into the function. I see zero reasons why anybody would push such logging into production. It behaves exactly the same way on your own computer as it would in production - it's just a pure function.

[tsimionescu]

I know that Haskell's lazyness adds an extra layer of complexity to this problem.

However, disregarding the implementation details, here is the abstract problem: I have a program which is reading some complex data structure from IO, applying a complex, pure pipeline to it, and sending the reply back through IO.

Now, say the output is not correct in some way. Your only chance of debugging the issue is to somehow visualize some of the intermediate values, right?

This being a pure pipeline, you don't need to have logging in production. You could just log the input value, and when a bug occurs, run the same input value from the logs through a modified version of the original pipeline with some logging sprinkled throughout - you're right on this side.

Now, I expect that there are many situations where adding the logging in production is still preferable - maybe the pure pipeline is in development and some kind sof issues are frequently occurring, maybe the pipeline takes too long to re-run, so it's just easier to have the logs from the first run etc.

[verttii]

OK Thanks for adding some context!

What I'd do is simply break down the larger pure function into smaller pure functions and sequencing them in the monad.

This way you would still retain purity with your functions but you could log every intermediate step by simply logging their output (and its corresponding input). Would probably make the code more maintainable as well.

From what I understand Haskell has great tooling for function profiling. Unfortunately, I got no experience with these yet so I can't say if they'd help you solve such problems.

Edit: Btw sounds like property based testing might work well as a solution to this kind of problem. It works really well with pure functions.