[Haskell-beginners] Getting Stuff out of IO Handles

Raphael Päbst raphael.paebst at googlemail.com
Fri Jun 24 15:07:38 CEST 2011

Thanks for your replies!
A short example of what I'm doing:

handle <- connectTo ... --opening the handle on a tcp connection
hPut handle message -- sending a ByteString
answer <- hGet handle n -- getting the answer back from the server
hClose handle

I have now several things I would like to do with the answer and my
question is, if I should put the functions into the handle or if I can
make the function with the handle of a type that returns answer, not
of IO () as it is currently.

Does this make sense? I hope so.


On 6/24/11, Kyle Murphy <orclev at gmail.com> wrote:
> I had started to say something about the circumstances under which you
> actually can use unsafePerformIO, but it sort of bogged down the reply and
> muddled the point I was trying to make. You seem to have done a better job
> explaining the circumstances under which you can actually use unsafePerfomIO
> safely than I was able to at the time.
> -R. Kyle Murphy
> --
> Curiosity was framed, Ignorance killed the cat.
> On Thu, Jun 23, 2011 at 19:46, Jared Hance <jaredhance at gmail.com> wrote:
>> > If you want to know if you can do something like:
>> >
>> > someFunction :: Int -> Int
>> > someFunction n = escapeIO $ someIOAction n
>> >
>> > then the answer is you shouldn't. It is technically possible, by using a
>> > function that every experienced haskell developer will tell you to never
>> > ever ever ever ever ever ever ever (get the picture) use, which is
>> > unsafePerformIO, but if you use unsafePerformIO it's likely that your
>> code
>> > won't do what you actually expect it to do, even if the type signatures
>> all
>> > check correctly. The IO Monad serves a very important purpose and
>> > implies
>> > certain things about a computation, likewise the absence of the IO Monad
>> > implies certain guarantees, and when you break those guarantees bad
>> things
>> > happen.
>> I'd like to clarify a bit here. The unsafePerformIO function has a use,
>> and should be used, but only in the right circumstances. The problem is
>> that often a function is referentially transparent, but haskell cannot
>> prove that it is because it uses the IO Monad.
>> The circumstance in which this crops up is usually when you use the FFI.
>> The function you call in C might return a pointer to something, rather
>> than the data itself. The pointer will usually be different every time,
>> so the result isn't referentially transparent. However, if you extract
>> the data from the pointer, that data _is_ referentially transparent and
>> is, as such, a good use case for unsafePerformIO.
>> So I would say an experienced programmer would say to never use it if
>> you don't know what you are doing, but if you do, use it when you need
>> it.
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners

More information about the Beginners mailing list