On Fri, 5 Sep 2008, Ashley Yakeley wrote:
Sittampalam, Ganesh wrote:
Ashley Yakeley wrote:
I really don't know enough about the RTS to know. The alternative
would be to keep all initialised values when the module is unloaded.
I'm guessing this is more feasible.
Easier, but a guaranteed
John Meacham wrote:
On Fri, Aug 29, 2008 at 04:33:50PM -0700, Dan Weston wrote:
C++ faced this very issue by saying that with global data,
uniqueness of initialization is guaranteed but order of
evaluation is not. Assuming that the global data are
merely thunk wrappers over some common data
Sittampalam, Ganesh wrote:
Can't you write two recursive modules with - that depend on
each other, so that there's no valid initialisation order?
Contrived example follows:
module Module1 where
glob1 :: IORef Int
glob1 - mod2 = newIORef
mod1 :: IO Int
mod1 = readIORef glob1
module Module2
Contrived example follows:
module Module1 (mod1) where
import Module2
glob1 :: IORef Int
glob1 - mod2 = newIORef
mod1 :: IO Int
mod1 = readIORef glob1
module Module2 (mod2) where
import Module1
glob2 :: IORef Int
glob2 - mod1 = newIORef
mod2 :: IO Int
mod2 =
On Tue, Sep 02, 2008 at 10:10:31AM +0100, Sittampalam, Ganesh wrote:
Contrived example follows:
module Module1 (mod1) where
import Module2
glob1 :: IORef Int
glob1 - mod2 = newIORef
mod1 :: IO Int
mod1 = readIORef glob1
module Module2 (mod2) where
import
David Roundy wrote:
On Tue, Sep 02, 2008 at 10:10:31AM +0100, Sittampalam, Ganesh wrote:
Arguably both of these cases are not ACIO simply because of the
non-termination effects, but it's not obvious to me how you tell just
by looking at either one's code together with the declared API of
On 2008 Sep 1, at 1:33, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote:
I'm afraid I don't see how this generalises to sharing something
across an entire process where the things that want to do the
sharing
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you
On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote:
I'm afraid I don't see how this generalises to sharing something across an
entire process where the things that want to do the sharing are not in or
controlled by the same shared
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
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
]
[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
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
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
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
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
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
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
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
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
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
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.
In article [EMAIL PROTECTED],
Keean Schupke [EMAIL PROTECTED] wrote:
Do you think implicit parameters could replace
top-level-things-with-identity?
I hadn't really thought of it before (and I don't use implicit
parameters much).
Yes, but I think people are clamouring for
On Wednesday 19 January 2005 12:52, Ashley Yakeley wrote:
I have been musing on the connection between data-types, modules,
classes, and implicit parameters, and wondering if there might be
some grand scheme to tie it all together. For instance, a module is
very similar to class with no type
I may have got this wrong, but I think you can do named instances
without any extensions,
by using datatypes and fundeps:
data Instance0
data Instance1
instance0 :: Instance0
instance0 = undefined
instance1 :: Instance1
instance1 = undefined
class Named a b | a - b
test :: a - b - b
instance
Perhaps one could have top-level implicit parameters (or top-level
contexts in general):
module (?myvar :: IORef Int) = Random where
Hi!
I suggested something very similar to this some months ago, syntax and all.
Nice to see I'm not the only one thinking along this lines.
On Wednesday 19 January 2005 14:31, Keean Schupke wrote:
I may have got this wrong, but I think you can do named instances
without any extensions,
by using datatypes and fundeps:
data Instance0
data Instance1
instance0 :: Instance0
instance0 = undefined
instance1 :: Instance1
instance1
On Wednesday 19 January 2005 21:20, Jorge Adriano Aires wrote:
Perhaps one could have top-level implicit parameters (or top-level
contexts in general):
module (?myvar :: IORef Int) = Random where
I suggested something very similar to this some months ago, syntax and all.
Nice to see I'm
Benjamin Franksen wrote:
Neither I nor the authors claim that their proposal is the ultimate grand
scheme, yet. Still I think there are very interesting ideas in there that
should be considered for experimental implementation or further research.
But thats interesting isn't it. If one
On Wednesday 19 January 2005 21:48, Keean Schupke wrote:
Benjamin Franksen wrote:
Neither I nor the authors claim that their proposal is the ultimate grand
scheme, yet. Still I think there are very interesting ideas in there that
should be considered for experimental implementation or further
Looking at the wiki summary [1] (very good, BTW), I have a question (I've
skipped much of the debate, so please just give a message pointer if I
missed something).
Why does RandomIO need to use the unsafePerformIO hack if its already in
the IO monad?
BTW, if the goal is to have a random
On Fri, Dec 03, 2004 at 10:05:08AM +, Graham Klyne wrote:
Looking at the wiki summary [1] (very good, BTW), I have a question (I've
skipped much of the debate, so please just give a message pointer if I
missed something).
Why does RandomIO need to use the unsafePerformIO hack if its
On Thu, Dec 02, 2004 at 09:08:21AM +, Keean Schupke wrote:
Ben Rudiak-Gould wrote:
Just a small comment on the Wiki page... it says
Several real-life examples of pure haskell code which needs fast global
variables to either be implemented efficiently or statically guarantee
their
Hi John,
I am not objecting to the top-level TWIs anymore - since I realised
contexts can be
provided by wrapping the MVar or IORef modules. I just thought the wiki
misrepresented
the calims of your examples (or maybe the claims are a little
exaggerated)...
As far as I can tell adding top
Nice summary.
What I think is missing is an explanation of when you would want this
feature (and when you wouldn't, more importantly). Here is the kind of
platonic dialogue that summarises my limited understanding:
[..dialogue snipped..]
This is good, and is the sort of thing that should
With regards to the following...
There are cases in which this parameterization costs convenience and
gains nothing -- for example, the standard library function (randomIO ::
Random a = IO a) cannot be implemented in Haskell without the
unsafePerformIO hack, yet there's nothing semantically
On Thu, Dec 02, 2004 at 10:53:57AM +, Keean Schupke wrote:
Hi John,
I am not objecting to the top-level TWIs anymore - since I realised
contexts can be
provided by wrapping the MVar or IORef modules. I just thought the wiki
misrepresented
the calims of your examples (or maybe the
Just a few minor nitpicks... mainly about the necessity of using certain
APIs,
however I think we are in general agreement...
Keean.
John Meacham wrote:
That example solves a different problem, I was never claiming that
there wern't efficient ways to solve the unique producer problem in
Keean Schupke wrote:
Ben Rudiak-Gould wrote:
[...]
Just a small comment on the Wiki page... it says
Several real-life examples of pure haskell code which needs fast global
variables to either be implemented efficiently or statically guarantee
their invariants are given in
I put up a wiki page summarizing the main proposals for top-level
mutable state. The type-dictionary approach isn't there yet, but there's
a space for it; I'll probably fill it in within the next 24 hours unless
someone else feels like doing it first.
Please add more detail, objections,
On Wednesday 01 Dec 2004 6:29 pm, Ben Rudiak-Gould wrote:
I put up a wiki page summarizing the main proposals for top-level
mutable state. The type-dictionary approach isn't there yet, but there's
a space for it; I'll probably fill it in within the next 24 hours unless
someone else feels like
On 1 Dec 2004, at 18:29, Ben Rudiak-Gould wrote:
Here's the page:
http://haskell.org/hawiki/GlobalMutableState
Nice summary.
What I think is missing is an explanation of when you would want this
feature (and when you wouldn't, more importantly). Here is the kind of
platonic dialogue that
43 matches
Mail list logo
