Hi Bulat, You wrote:

there is common proposal that i support. example of its use:

i :: IORef Int i <- newIORef 1

with a semantics equivalent to current use of usafePerformIO+INLINE in GHC

Are the details of this posted anywhere? Is there a ticket for this? I assume you mean that this will work for anything in the IO monad, not just newIORef. I really like this approach - it is much cleaner than a pragma with unsafePerformIO. Regards, Yitz

On Thu, 1 Feb 2007, David House wrote:

I think that's too safe-looking. Anything that translates to something involving unsafe* should be tagged with 'unsafe' somewhere as well. Also, as unsafe* is still compiler specific, I think a pragma is probably most appropriate:

{-# GLOBAL-MUTVAR #-} i :: IORef Int i = unsafePerformIO (newIORef 1)

There might be a more sensible way to handle it while retaining the meat of Bulat's proposal, but I don't think it can really be done without making significant changes to the module system - it amounts to having initialiser actions, and once you've got those there're all sorts of things that rapidly become desirable. I've had a couple of occasions where being able to treat an entire module as being within a monad or an arrow could've been used to good effect though. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez

On Thu, Feb 01, 2007 at 04:51:39PM +0000, David House wrote:

I think that's too safe-looking. Anything that translates to something involving unsafe* should be tagged with 'unsafe' somewhere as well. Also, as unsafe* is still compiler specific, I think a pragma is probably most appropriate:

then pretty much everything will have to be 'unsafe' :) look inside of how the libraries are implemented and they all involve unsafe operations at some point, 'unsafe' does not mean unsafe always, it means it is up to the user to provide proofs of certain properties rather than the compiler. when such a proof is provided and abstracted by an API, then it is safe. As to this particular extension, depending on the exact details it can be safe or unsafe and make different demands on the implementation. luckily, pretty much all of this was worked out in a discussion a while ago, the trick was to create a new type 'ACIO' which contained only 'good' top level operations. There will be an 'unsafeIOToACIO' of course, I mean, ACIO functions have to be implemented somehow. :) John -- John Meacham - ⑆repetae.net⑆john⑈