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⑈