Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO

[John Meacham]

On Fri, Feb 22, 2008 at 10:51:12AM +0000, Duncan Coutts wrote:
> > However, I am worried about the 'Inline' in the other one, in jhc,
> > unsafePerformIO is always inlined, it uses a different trick (my
> > 'dependingOn' primitive) to ensure the world is not unified with another
> > one. 
> > 
> > Can we come up with a term that describes the difference other than
> > 'inline' as that is a ghc specific quirk.
> 
> Mm, you're right, it is ghc specific. The semantics are less to do with
> inlining (though that's the perf advantage) and more about doing
> dangerous things with the world token.
> 
> Can anyone suggest a better name?

hmm.. well the issue is that the world token may be unified with any
other use of the world token... this is different than the issue of
whole unsafePerformIO actions being unified via CSE.

basically in jhc, it is solved by having newworld be of type

newWorld__ :: a -> World__

which conjures up a world that depends on its arbitrary first argument,
since the world can be made to depend on the argument to
unsafePerformIO, it can't be accidentally unified with other occurances
of new epheremel worlds.

so.. what does it mean when we don't have this? I am not sure.. it sort
of depends on what exact IO primitives we call...  what it comes down to
is "this computation is safe to apply to the same world as any other
computation." meaning, it can't change the world in any way (including
things like allocating memory). perhaps

unsafeImmutableIO, unsafeUnworldlyIO, unsafePristineIO, unsafeInspectIO,
unsafeImpotentIO (sort of similar to Idempotent..)?

hmm... I dunno.


> 
> > incidentally, jhc has another form of unsafePerformIO that does not wrap
> > its argument in a new exception handler. It can be used when you know
> > the argument won't raise an ioError or if it does, it handles them
> > itself. (normal calls to things like error and pattern match failures
> > are fine. it is just haskell98 io errors that metter for this one)
> 
> Right, GHC misses this once because it doesn't wrap any in an exception
> handler since its exception mechanism for IO errors is the same as for
> 'error'. If you have a good name and documentation then propose it now.

It probably isn't worth making portable at the moment as it is rather
jhc specific.

-- 
John Meacham - ⑆repetae.net⑆john⑈