RE: [Haskell-cafe] Top-level TVars
Yes, they do | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joel | Reymont | Sent: 14 December 2005 20:39 | To: Tomasz Zielonka | Cc: Simon Marlow; Haskell-Cafe Cafe | Subject: Re: [Haskell-cafe] Top-level TVars | | | On Wed, Dec 14, 2005 at 02:17:17PM -, Simon Marlow wrote: | Suppose you create two top-level IORefs with the same type, like | this: | |var1 = unsafePerformIO $ newIORef 0 |var2 = unsafePerformIO $ newIORef 0 | | GHC's CSE optimisation will common these up - after all, it's the | same | expression, so it must yield the same result, right? | | Do these have to be within the same module for the CSE optimization | to kick in? | | -- | http://wagerlabs.com/ | | | | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top-level TVars
On 14 December 2005 20:39, Joel Reymont wrote: On Wed, Dec 14, 2005 at 02:17:17PM -, Simon Marlow wrote: Suppose you create two top-level IORefs with the same type, like this: var1 = unsafePerformIO $ newIORef 0 var2 = unsafePerformIO $ newIORef 0 GHC's CSE optimisation will common these up - after all, it's the same expression, so it must yield the same result, right? Do these have to be within the same module for the CSE optimization to kick in? Right now, yes. But there's no guarantee that GHC might not get cleverer in the future. We're skating on really thin ice here. I'm not particularly keen on re-opening the discussion about top-level IO, but we do need *something* better. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top-level TVars
newTVarIO in the HEAD, and therefore it's in any nightly-build snapshot, which you can freely download. The next major release will be 6.6, but it's a few months off. Meanwhile I hope you can use the workaround that Tomasz posted. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joel | Reymont | Sent: 13 December 2005 18:08 | To: Haskell-Cafe Cafe | Subject: [Haskell-cafe] Top-level TVars | | Can this be done now or is this a GHC 6.5 feature? | | My combination of unsafePerformIO with atomically $ newTVar does not | seem to be working. | | Thanks, Joel | | P.S. What is the ETA for 6.5? | | On Mon, Dec 05, 2005 at 10:50:13AM -, Simon Peyton-Jones wrote: | | It turns out to be easy to provide | | newTVarIO :: a - IO (TVar a) | | which you can call from inside 'unsafePerformIO'. That means you can | allocate top-level TVars without fuss. | | | -- | http://wagerlabs.com/ | | | | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top-level TVars
On 13 December 2005 18:34, Tomasz Zielonka wrote: On Tue, Dec 13, 2005 at 06:08:23PM +, Joel Reymont wrote: Can this be done now or is this a GHC 6.5 feature? My combination of unsafePerformIO with atomically $ newTVar does not seem to be working. Here is an example how you can initialize a top-level STM variable. http://www.uncurry.com/repos/TimeVar/TimeVar.hs It just forks a new thread inside unsafePerformIO, it runs atomically in it and passes the result through ordinary MVar. A cheaper way is just to seq the top-level TVar at the beginning of Main.main. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level TVars
On Wed, Dec 14, 2005 at 09:51:16AM -, Simon Marlow wrote: Here is an example how you can initialize a top-level STM variable. http://www.uncurry.com/repos/TimeVar/TimeVar.hs It just forks a new thread inside unsafePerformIO, it runs atomically in it and passes the result through ordinary MVar. A cheaper way is just to seq the top-level TVar at the beginning of Main.main. Yes, I tried that approach. However, imagine telling users of your library to do that in every program (withSocketsDo comes to mind). Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top-level TVars
On 14 December 2005 09:57, Tomasz Zielonka wrote:
On Wed, Dec 14, 2005 at 09:51:16AM -, Simon Marlow wrote:
Here is an example how you can initialize a top-level STM variable.
http://www.uncurry.com/repos/TimeVar/TimeVar.hs
It just forks a new thread inside unsafePerformIO, it runs
atomically in it and passes the result through ordinary MVar.
A cheaper way is just to seq the top-level TVar at the beginning of
Main.main.
Yes, I tried that approach. However, imagine telling users of
your library to do that in every program (withSocketsDo comes
to mind).
Well sure, but it's only a temporary problem. And you also have to tell
them to use {-# NOINLINE #-} and -fno-cse :-)
Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level TVars
On Wed, Dec 14, 2005 at 10:03:42AM -, Simon Marlow wrote:
Well sure, but it's only a temporary problem. And you also have to tell
them to use {-# NOINLINE #-} and -fno-cse :-)
-fno-cse is also neccesary? Oops, I didn't know that. Can I simply
place it in {-# OPTIONS -fno-cse #-} ?
Best regards
Tomasz
--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level TVars
I'm a bit lost in the discussion. Why do I need -fno-cse and how do I
seq at the top-level?
On Dec 14, 2005, at 10:05 AM, Tomasz Zielonka wrote:
On Wed, Dec 14, 2005 at 10:03:42AM -, Simon Marlow wrote:
Well sure, but it's only a temporary problem. And you also have
to tell
them to use {-# NOINLINE #-} and -fno-cse :-)
-fno-cse is also neccesary? Oops, I didn't know that. Can I simply
place it in {-# OPTIONS -fno-cse #-} ?
--
http://wagerlabs.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Top-level TVars
On 14 December 2005 10:11, Joel Reymont wrote:
I'm a bit lost in the discussion. Why do I need -fno-cse and how do I
seq at the top-level?
On Dec 14, 2005, at 10:05 AM, Tomasz Zielonka wrote:
On Wed, Dec 14, 2005 at 10:03:42AM -, Simon Marlow wrote:
Well sure, but it's only a temporary problem. And you also have to
tell them to use {-# NOINLINE #-} and -fno-cse :-)
-fno-cse is also neccesary? Oops, I didn't know that. Can I simply
place it in {-# OPTIONS -fno-cse #-} ?
Suppose you create two top-level IORefs with the same type, like this:
var1 = unsafePerformIO $ newIORef 0
var2 = unsafePerformIO $ newIORef 0
GHC's CSE optimisation will common these up - after all, it's the same
expression, so it must yield the same result, right?
To turn this off, we use -fno-cse. It's good practice to use -fno-cse
whenever you use top-level mutable objects of any kind. You can put it
in the source file:
{-# OPTIONS_GHC -fno-cse #-}
at the top of your file.
Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level TVars
On Wed, Dec 14, 2005 at 02:17:17PM -, Simon Marlow wrote:
Suppose you create two top-level IORefs with the same type, like this:
var1 = unsafePerformIO $ newIORef 0
var2 = unsafePerformIO $ newIORef 0
GHC's CSE optimisation will common these up - after all, it's the same
expression, so it must yield the same result, right?
Ah, yes. Thanks for explanation.
To turn this off, we use -fno-cse. It's good practice to use -fno-cse
whenever you use top-level mutable objects of any kind. You can put it
in the source file:
{-# OPTIONS_GHC -fno-cse #-}
at the top of your file.
How about a new pragma:
{-# OPTIMIZER_HANDS_OFF var1 #-}
;-)
Best regards
Tomasz
--
I am searching for a programmer who is good at least in some of
[Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level TVars
On Wed, Dec 14, 2005 at 02:17:17PM -, Simon Marlow wrote: Suppose you create two top-level IORefs with the same type, like this: var1 = unsafePerformIO $ newIORef 0 var2 = unsafePerformIO $ newIORef 0 GHC's CSE optimisation will common these up - after all, it's the same expression, so it must yield the same result, right? Do these have to be within the same module for the CSE optimization to kick in? -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level TVars
On Tue, Dec 13, 2005 at 06:08:23PM +, Joel Reymont wrote: Can this be done now or is this a GHC 6.5 feature? My combination of unsafePerformIO with atomically $ newTVar does not seem to be working. Here is an example how you can initialize a top-level STM variable. http://www.uncurry.com/repos/TimeVar/TimeVar.hs It just forks a new thread inside unsafePerformIO, it runs atomically in it and passes the result through ordinary MVar. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
