[Haskell-cafe] what are the safety conditions for unsafeIOToST
gcross at phys.washington.edu
Tue Apr 6 20:40:19 EDT 2010
I would venture that the condition under which unsafeIOtoST would be safe is if all of the computations you are performing in the IO monad are only changing state that is local to the computation within the ST monad in which you are running. (For example, if there were no STRef type then you could emulate it using IORefs, and this would be safe since the IORefs couldn't leak outside of the ST monad.) It sounds like Unique doesn't satisfy this property since the side-effect of creating a new Unique will leak out of the ST monad. It would probably be better to use some other stream of unique values that runs inside the ST monad.
On Apr 6, 2010, at 5:30 PM, Roman Leshchinskiy wrote:
> On 07/04/2010, at 07:33, Nicolas Frisby wrote:
>> I haven't been able to find it via Google or Haddock. An old message
>> suggests is was just a matter of exceptions?
> I don't think that's correct. You can implement unsafePerformIO in terms unsafeIOToST:
> unsafePerformIO :: IO a -> a
> unsafePerformIO p = runST (unsafeIOToST p)
> In fact, the only safe-ish use for it I have found is to use Storable-related functions in ST, hoping that the instances don't actually use any real IO functionality. Arguably, this shouldn't be necessary as Storable should live in ST anyway.
>> I only want to use the IO for generating Data.Uniques to pair with
>> STRefs in order to make a map of them. I'm guessing this would be a
>> safe use since it's exception free (... right?).
> It's hard to tell without looking at your code. But if you are generating Uniques in ST then it's probably unsafe:
> foo :: () -> Unique
> foo _ = runST (unsafeIOToST newUnique)
> What's the value of foo ()?
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe