How to write a haskell function without IO in type sig by hiding 'state' changes?

Yes! Haskell can do this. The ST monad If you actually use mutable state (registers), that are entirely hidden from the observer outside the function, then you are in the ST monad, a monad for memory effects only.

You enter the ST world via runST, and when you exit the function, all effects are guaranteed to not be visible. It is precisely the right computational environment for working with local, mutable state. Purely functional state: the State monad If, however, you're not actually mutating registers or cells, but rather updating a purely functional value many times, a simpler environment is available: the State monad.

This doesn't allow mutable state, but gives an illusion of local state. IO, and unsafePerformIO Finally, if you have local, mutable effects, like in the ST monad, but for some reason or another, you are going to need IO operations on that state (such as via an FFI call), you can simulate the ST monad, with almost as much safety, by using unsafePerformIO, instead of runST, to introduce a local IO environment. As the IO monad doesn't have nice types to enforce abstraction, you will need to manually assure yourself that the side effects will not be observable.

Another nice benefit of the ST monad is that it's extremely efficient. I've often found ST code to be faster than equivalent IO code. – John L May 20 at 22:54 @John L, in fact, IO is defined in terms of ST, with some magic extra hooks.

– Don Stewart May 20 at 22:57 Don,mutable state is entirely hidden from observer outside function. I read a 1994 paper called Lazy Functional State Threads by John Launchbury & Simon Peyton, which says Some algorithms make critical internal use of updatable state,even though their external specification is purely functional .. we present a way of securely encapsulating stateful computations that manipulate multiple,named,mutable objects,in the context of a non-strict,purely-functional language. Paper,which talks about ST was a bit too technical first time I read it.

I will read it again & implement f8,f9 using ST monad. – Babu Srinivasan May 21 at 5:28 Link to paper I mentioned: Lazy Functional State Threads by John Launchbury and Simon Peyton Jones – Babu Srinivasan May 21 at 5:32.

If you imported that function using the FFI, just remove the IO from the return type. Else, use unsafePerformIO :: IO a -> a from System.IO.Unsafe. Please note, that this function is one of the most dangerous functions in Haskell.

Don't use it, if you're not really shure about the consequences. But for your purpose, it seems okay.

6 Should probably note that one of the few "correct" uses of unsafePerformIO is as a flat assertion to the compiler that a function actually is externally pure, which is exactly what this question is about. Most of the ways that unsafePerformIO can bite you arise from using it on functions that are only "mostly" pure in some sense. – C.A. McCann May 20 at 15:40 Perhaps the most annoying mis-use of unsafePerformIO is in the presence of static buffers (not a thread-safe use), so be very careful!

– Thomas M. DuBuisson May 20 at 15:45 2 @TomMD: Sometimes I think it's counterproductive to talk about purity in terms of "side effects" that involve "doing something" as much as Haskell programmers tend to. The most insidious bugs in impure functions--and in most impure languages, really--are often those involving read-only access to the outside world.

– C.A. McCann May 20 at 17:13.

Yes, this would be a legitimate use of unsafePerformIO. But it's only OK if you are really sure there are no visible effects.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.