Hi,
I am pleased to announce the first public release of global-variables. A
package
providing a global namespace for IORefs, MVars, and TVars.
Hackage URL: http://hackage.haskell.org/package/global-variables-1.0
Source: http://bitbucket.org/jmg/global-variables/
Description
On Wed, 12 Oct 2011, Jean-Marie Gaillourdet wrote:
* Simplify the configuration problem - at least for code in the
IO monad.
Note, that this library does not encourage sloppy software design by
re-introducing all bad effects of global variables.
But isn't this kind of solution
Begin forwarded message:
From: Jean-Marie Gaillourdet j...@gaillourdet.net
Subject: Re: [Haskell] ANN: global-variables-1.0
Date: 12. Oktober 2011 20:27:16 MESZ
To: Henning Thielemann lemm...@henning-thielemann.de
Hi,
On 12.10.2011, at 20:20, Henning Thielemann wrote:
On Wed, 12
On Mon, Dec 01, 2008 at 05:30:33PM -0800, Judah Jacobson wrote:
You can limit the size of that stub file using:
foreign import ccall progname progname :: Ptr (Ptr CChar)
which lets you access that global variable and write the
getters/setters in Haskell rather than C.
this solves my
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global variable to be
defined. A C program using my_function, one of the library functions,
would look like:
char progname[] = a_program_name;
int
main
On Mon, Dec 1, 2008 at 4:39 PM, Andrea Rossato
[EMAIL PROTECTED] wrote:
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global variable to be
defined. A C program using my_function, one of the library
On Mon, Dec 1, 2008 at 4:55 PM, Evan Laforge [EMAIL PROTECTED] wrote:
On Mon, Dec 1, 2008 at 4:39 PM, Andrea Rossato
[EMAIL PROTECTED] wrote:
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global
On Mon, Dec 01, 2008 at 04:55:14PM -0800, Evan Laforge wrote:
On Mon, Dec 1, 2008 at 4:39 PM, Andrea Rossato
[EMAIL PROTECTED] wrote:
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global
, 2008 at 4:39 PM, Andrea Rossato
[EMAIL PROTECTED] wrote:
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global variable to be
defined. A C program using my_function, one of the library
Taral wrote:
On 5/23/07, Adrian Hey [EMAIL PROTECTED] wrote:
I think I still prefer..
var :: IORef Int
var - newIORef 3
So do I. For one very good reason: this syntax could be defined as a
constructor syntax and guaranteed to run before main.
Or even at compile time (which is why I think
On 5/24/07, Adrian Hey [EMAIL PROTECTED] wrote:
Taral wrote:
The other syntaxes proposed don't strike me as sufficiently rigorous.
Me neither. It's always been a great source of puzzlement to me why this
very simple and IMO conservative proposal should be so controversial.
Unless someone can
Adrian Hey wrote:
Taral wrote:
On 5/23/07, Adrian Hey [EMAIL PROTECTED] wrote:
I think I still prefer..
var :: IORef Int
var - newIORef 3
So do I. For one very good reason: this syntax could be defined as a
constructor syntax and guaranteed to run before main.
Or even at compile time
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time? (Well, I guess you could,
but that wouldn't still be
David House wrote:
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time? (Well, I guess you could,
but that
On 2007-05-24, David House wrote:
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time? (Well, I guess you
Aaron Denney wrote:
On 2007-05-24, David House wrote:
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time?
Isaac Dupree wrote:
var :: IORef Int
var = {-# EVALUATE_THIS_TEXT_ONLY_ONCE #-} (unsafePerformIO (newIORef 3))
I think I still prefer..
var :: IORef Int
var - newIORef 3
or, more likely..
var :: IORef Int
var - ACIO.newIORef 3
The - syntax should make the intended semantics clear and
On 5/23/07, Adrian Hey [EMAIL PROTECTED] wrote:
I think I still prefer..
var :: IORef Int
var - newIORef 3
So do I. For one very good reason: this syntax could be defined as a
constructor syntax and guaranteed to run before main.
The other syntaxes proposed don't strike me as sufficiently
such that they need
recalculation later, would need a special case for global variables to
make them work.
i.e. I'm not sure if there exists a reasonable pragma while the code
still uses unsafePerformIO.
Hmm
How about
so,
{-# NOINLINE var #-}
var :: IORef Int
var = unsafePerformIO (newIORef 3)
- --
var
| I see no need two answer this again I believe I have already made my
| views perfectly clear already and provided ample evidence to justify
| them. Surely I don't need to do it again?
Is there a Wiki page about this somewhere? Often email gets into a loop
because not everyone reads
On 21-mei-2007, at 9:31, Simon Peyton-Jones wrote:
| I see no need two answer this again I believe I have already made my
| views perfectly clear already and provided ample evidence to justify
| them. Surely I don't need to do it again?
Is there a Wiki page about this somewhere? Often email
Jules Bean wrote:
I've pretty much convinced it's wrong. There should be one and only
one main from which all subsequent IO activity derives. But creating
internal state in the form of mutable data structures is not an IO
activity. It just so happens that at the moment the only way to do this
is
Adrian Hey wrote:
Jules Bean wrote:
I've pretty much convinced it's wrong. There should be one and only
one main from which all subsequent IO activity derives. But creating
internal state in the form of mutable data structures is not an IO
activity. It just so happens that at the moment the
[cc'ing HPrime]
Isaac Dupree wrote:
The unsafePerformIO hack being used is not very satisfactory given how
many optimizations make it difficult to use safely in practice. This
hack is also used many places. I would be happier if that situation
were not true, and I suspect there's something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian Hey wrote:
[cc'ing HPrime]
Isaac Dupree wrote:
The unsafePerformIO hack being used is not very satisfactory given how
many optimizations make it difficult to use safely in practice. This
hack is also used many places. I would be
Isaac Dupree wrote:
Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or
USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE
would be a good first step... if successful it would remove the
occasional need for -fno-cse for a whole module in GHC, at least.
I have a hard
Adrian Hey wrote:
Also, I don't know if the OP was a noob, but telling people (especially
noobs) that if they can't figure out how to solve a problem without
using a global variable then that must be down to inexperience and
general cluelessness on their part just seems wrong to me. It simply
Jules Bean wrote:
That's not my point. newIORef creates unique names (references). The
whole job of newIORef is to create unique names; unique names which
refer to little tiny bits of state parcelled up somewhere in that
mysterious IO monad. It is the scope of this uniqueness I'm talking
Albert Y. C. Lai wrote:
Adrian Hey wrote:
Also, I don't know if the OP was a noob, but telling people (especially
noobs) that if they can't figure out how to solve a problem without
using a global variable then that must be down to inexperience and
general cluelessness on their part just seems
Hello Isaac,
Sunday, May 20, 2007, 6:41:54 PM, you wrote:
Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or
USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE
would be a good first step...
or LOOK_BUT_DON'T_TOUCH :)
--
Best regards,
Bulat
| and (at worst) are evil. These people are quite simply wrong and
| should be ignored :-)
|
| Adrian Hey is not only wrong, but actually evil. He should be ignored. :-)
|
| I am right, I might well be evil, and if past experience is anything to
| go by I already know that I will be ignored.
On Thu, 17 May 2007, Jules Bean wrote:
Eric wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
(Perhaps annoyingly) the answer to this question, like so many other
questions on this list, is a question. What are you trying to do
[I agree with your points, but...]
Adrian Hey wrote:
I've pretty much convinced it's wrong. There should be one and only
one main from which all subsequent IO activity derives. But creating
internal state in the form of mutable data structures is not an IO
activity. It just so happens that at
of complete programs
or processes, implementations that don't use global variables are
possible. But this does not hold at the level of individual IO library
API's. If we want to keep our software *modular* (I take we do), then
we need top level mutable state.
That's assuming you feel having an explicit
Simon Peyton-Jones wrote:
For example, I was looking back at your ACIO mail a couple of months ago,
when I was thinking about concurrency.
Actually, this is Ian Starks proposal..
http://www.haskell.org/pipermail/haskell-cafe/2004-November/007664.html
..but is one with which I agree. I just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian Hey wrote:
Furthermore, if it is going to take this state handle as an explicit
argument then you need to provide some way for users to get this
state handle. This could be by..
1 - Making it an argument of main.
2 - Exposing a
On Thu, May 17, 2007 at 07:25:03PM +0100, Adrian Hey wrote:
The above hack is not actually Haskell. It's a hack, and it depends on
the particular implementation characteristics of GHC. It is not
unreasonable to imagine that a future GHC might contain different
compilation techniques (I
On Thu, May 17, 2007 at 11:00:18PM +0100, Jules Bean wrote:
I'm not sure that's quite to the point. Clearly we can set up state at
the top of our main action:
main = do
sockstate - initSocks
graphstate - initGraphics
...
disposeGraphics graphstate
disposeSocks sockstate
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
E.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
eeoam:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
E.
The usual way is to run the code that needs a global variable in a State monad.
The next answer is: you don't really need global variables, since you
don't have mutable variables
On 17/05/07, Eric [EMAIL PROTECTED] wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
You can pass around an environment with the State or Reader monads
(read/write and read-only respectively). If you want to do IO with the
data you'll
[EMAIL PROTECTED] wrote:
On 17/05/07, Eric [EMAIL PROTECTED] wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
You can pass around an environment with the State or Reader monads
(read/write and read-only respectively). If you want to do IO
On Thu, 17 May 2007 14:41:33 +0100
Eric [EMAIL PROTECTED] wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
E.
Another alternative, for write-once variables, is implicit parameters.
--
Robin
On Thu, May 17, 2007 at 02:41:33PM +0100, Eric wrote:
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
Just declare them at the top level, as a function but without
arguments:
===
x
Eric wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
(Perhaps annoyingly) the answer to this question, like so many other
questions on this list, is a question. What are you trying to do?.
The reason for this is that haskell's
Eric wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
I assume what you're looking for is to be able to have IORefs,MVars
Chans etc at the top level. The standard (for want of a better word)
way to do this is known commonly known
and assert that so called global variables are (at best) unnecessary
and (at worst) are evil. These people are quite simply wrong and
should be ignored :-)
Adrian Hey is not only wrong, but actually evil. He should be ignored. :-)
The above hack is not actually Haskell. It's a hack, and it depends
On 17/05/07, Jules Bean [EMAIL PROTECTED] wrote:
I'd be willing to take a sportsman's bet that the original poster
does not actually need to use this hack; I doubt his application falls
into the categories you have outlined. I would discourage people from
using this hack unless it is, in fact,
Eric [EMAIL PROTECTED] writes:
H|i,
Does anyone know of a simple and straightforward way to use
global variables in Haskell?
No, no-one does. Global variables are neither simple nor
straightforward. :-P
In addition to what others have said (assuming you don't
just mean providing a name
Jules Bean wrote:
BTW, this is the commonly the subject of flame wars on the Haskell
mailing lists because there appear to be many who passionately believe
and assert that so called global variables are (at best) unnecessary
and (at worst) are evil. These people are quite simply wrong and
should
stateless?).
I wouldn't dispute the assertion that at the level of complete programs
or processes, implementations that don't use global variables are
possible. But this does not hold at the level of individual IO library
API's. If we want to keep our software *modular* (I take we do), then
we
a hard one.
I wouldn't dispute the assertion that at the level of complete programs
or processes, implementations that don't use global variables are
possible. But this does not hold at the level of individual IO library
API's. If we want to keep our software *modular* (I take we do), then
we need
Albert Y. C. Lai wrote:
There is no reality about global variables. Global variables are
syntactic sugar for local variables. That is the reality we need to
think through. This syntactic sugar streamlines many practical programs
and is indeed valuable.
I agree that the use of the term global
On 5/17/07, Adrian Hey [EMAIL PROTECTED] wrote:
Jules Bean wrote:
BTW, this is the commonly the subject of flame wars on the Haskell
mailing lists because there appear to be many who passionately believe
and assert that so called global variables are (at best) unnecessary
and (at worst
turn the Haskell module
system into an OO system, just that maybe it would be wise to borrow
some ideas from that paradigm.
Well, I'm a little unclear as to how the discussion shifted from
global variables to modules, but as long as we're here: Rather than
looking at OO languages, why not take
On Mon, 29 Nov 2004, Simon Peyton-Jones wrote:
This unfortunate observabilty of an ordering (or hash value) that is
needed only for efficient finite maps, is very annoying. I wish I knew
a way round it. As it is we can pick
a) expose Ord/Hash, but have unpredictable results
b)
(indexing with TypeRep)
This is yet another incidence where Robert Will's ByMaps would be very useful
In fact GHC at least *already* generates a unique integer for each TypeRep.
A good idea, since it means comparisons can be done in unit time.
Thus indexing can be done trivially using this
On Monday 29 November 2004 11:35, George Russell wrote:
(indexing with TypeRep)
This is yet another incidence where Robert Will's ByMaps would be
very useful
In fact GHC at least *already* generates a unique integer for each
TypeRep. A good idea, since it means comparisons can be done
Benjamin wrote (snipped):
Typeable would be completely safe if the only way to declare instances
would be to derive them, but this is only practical if it can be done
from anywhere outside the data type definition.
Unfortunately this would also outlaw some legitimate uses of Typeable.
In
On Mon, Nov 29, 2004 at 03:09:53PM -, Simon Peyton-Jones wrote:
| In fact GHC at least *already* generates a unique integer for each
| TypeRep. A good idea, since it means comparisons can be done in unit
| time. Thus indexing can be done trivially using this integer as a
| hash
On Mon, Nov 29, 2004 at 11:57:31AM +0100, Benjamin Franksen wrote:
Can anyone think of a situation where adding a derived instance to an
abstract data type breaks one of its invariants?
Yes, I was thinking of this the other day,
newtype LessThan5 = LessThen5 Int
new x | x 5 = LessThen5 x
On Friday 26 November 2004 08:39, George Russell wrote:
Benjamin Franksen wrote (snipped):
What non-standard libraries have I used (that you don't)?
OK, but you have to test every element of the dictionary with fromDynamic
until you find one with the type you want, which is not a good idea
On Friday 26 November 2004 08:39, you wrote:
Benjamin Franksen wrote (snipped):
What non-standard libraries have I used (that you don't)?
OK, but you have to test every element of the dictionary with fromDynamic
until you find one with the type you want, which is not a good idea if the
[for the 4th time moving this discussion to cafe]
On Friday 26 November 2004 08:39, you wrote:
Benjamin Franksen wrote (snipped):
Doesn't that run contrary to Adrian Hey's oneShot example/requirement?
Remind me again what Adrian Hey's oneShot example/requirement is ...
On Friday 26 November 2004 14:12, Benjamin Franksen wrote:
I still can't see any reason why each single Haskell thread should have its
own searate dictionary. Contrary, since it is common to use forkIO quite
casually, and you expect your actions to do the same thing regardless of
which thread
is probably much simpler than mine because you don't
implement withEmptyDict. I'm really quite keen about withEmptyDict, because
one of the MAJOR conceptual problems I have with unsafePerformIO global
variables
is that you only get one universe, corresponding to the Haskell program.
There shouldn't
George Russell [EMAIL PROTECTED] writes:
Your implementation is probably much simpler than mine because
you don't implement withEmptyDict. I'm really quite keen about
withEmptyDict, because one of the MAJOR conceptual problems I have
with unsafePerformIO global variables is that you only get
()
getGlobal :: Typeable a = IO a
Your implementation is probably much simpler than mine because you don't
implement withEmptyDict. I'm really quite keen about withEmptyDict,
because one of the MAJOR conceptual problems I have with unsafePerformIO
global variables is that you only get one
Marcin wrote (snipped):
I think global variables are a lot less evil if they behave as if they
were dynamically scoped, like Lisp special variables.
That is, there is a construct which gives the variable a new mutable
binding visible in the given IO action. It's used more often than
Benjamin Franksen wrote (snipped):
Doesn't that run contrary to Adrian Hey's oneShot example/requirement?
Remind me again what Adrian Hey's oneShot example/requirement is ...
Well, that's indeed one major problems with global variables. Sure, you can
try to solve it with multiple dictionaries
global variables without
unsafePerformIO, NOINLINE and other such horrors.
This is funny. When I got no immediate reaction from you, I started
implementing it myself. I ended up with something similar. It has less
features but is also a lot simpler. This is the interface:
initGlobal :: Typeable
Benjamin Franksen wrote:
label1 = unique Uniq1
label2 = unique Uniq2
global1 = functionalNewMVar label1 True
global2 = functionalNewMVar label1 (117::Int)
No dice. Your example inadvertently shows why: you used label1 when
creating both global1 and global2, and now I can write
On Thursday 25 November 2004 01:14, Ben Rudiak-Gould wrote:
Benjamin Franksen wrote:
label1 = unique Uniq1
label2 = unique Uniq2
global1 = functionalNewMVar label1 True
global2 = functionalNewMVar label1 (117::Int)
No dice. Your example inadvertently shows why: you used
Benjamin Franksen wrote:
My god, what a stupid mistake. I should just give it up... :-(
Funny you should say that, because I made the same mistake two weeks ago
and felt the same way:
http://www.haskell.org/pipermail/haskell-cafe/2004-November/007556.html
Live and learn...
-- Ben
On Thu, 25 Nov 2004 01:46:03 +, Ben Rudiak-Gould
[EMAIL PROTECTED] wrote:
Benjamin Franksen wrote:
My god, what a stupid mistake. I should just give it up... :-(
Funny you should say that, because I made the same mistake two weeks ago
and felt the same way:
as
evil in C or OS supplied resources as it is in Haskell.
The evil is in the world in the form of C libraries with hidden global
variables and hardware with non-readable registers.
What I am arguing for is to *contain* this disease by forcing a solution to
happen outside of Haskell.
What you
On Friday 12 Nov 2004 5:42 pm, Judah Jacobson wrote:
On Fri, 12 Nov 2004 14:53:33 +, Adrian Hey [EMAIL PROTECTED] wrote:
On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
On the other hand, these are perfectly safe:
once' :: IO a - IO (IO a)
oncePerString ::
I'm not sure I understand what problem you think there is. Are the inits
you're talking about module inits? If so, I don't think there's a problem,
for several reasons.
The idea under discussion is that a top level (x - newThing) should
be lazy, (no action at all occurs until value of x is
On Saturday 13 Nov 2004 9:15 am, Keean Schupke wrote:
I'm not sure I understand what problem you think there is. Are the inits
you're talking about module inits? If so, I don't think there's a problem,
for several reasons.
The idea under discussion is that a top level (x - newThing) should
Well lets say:
userInit - oneShot realInit
where realInit defines an MVar used for state storage that is used in
module A to implement
an accumulator. Now module B does some maths using the accumulator, and
module C does
some maths using the accumulator. If Main uses functions defined in
On Saturday 13 Nov 2004 10:39 am, Keean Schupke wrote:
Actually, I Think I'm wrong - I think its not even safe if you cannot
export the '-' def. If any functions which use it are exported you are
in the same situation. I cannot say the kind of code in the example I
gave is good, can you?
At 16:07 11/11/04 +, Keith Wansbrough wrote:
Graham Klyne wrote:
At 12:27 11/11/04 +, Ben Rudiak-Gould wrote:
[..]
going to be safe, because it's just not the case that
x = once (newIORef ())
y = x
has the same intended meaning as
x = once (newIORef ())
y =
So you say (and I do agree). But how can I *observe* that they are the same?
Well, not with a single program run (obviously). But it is the case
that for any program P and input sequence X (i.e., keys
pressed):
running P with X
and
running {foo = getChar; P'} with X (where P' is P with all
than dogma and superstitious fear about
the evils of global variables :-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
the evils of global variables :-)
I agree about not wearing a hair-shirt, but how do you propose to solve
the multiple import problem: B imports A, C imports A, D imports B C.
Now the top level inits (a - computation) in A, do they happen once,
defining
the same init A.a, do they happen twice, perhaps
Should values really depend on the order of includes? Even if you limit
things to just
newChan in top level '-' you still don't know if A.a in B the same A.a
in C. Perhaps it
is enough to say A.a only exists once no matter how many times it is
directly or
indirectly imported?
This strikes me
This still has a problem. Lets say B implements some useful function that
relies on A. Now also C implements some different useful function and also
relies on A in its implementation. If there is only one A.a then using
both B
and C features in the same code will potentally break both B and C.
On Fri, 12 Nov 2004 14:53:33 +, Adrian Hey [EMAIL PROTECTED] wrote:
On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
On the other hand, these are perfectly safe:
once' :: IO a - IO (IO a)
oncePerString :: String - IO a - IO a
oncePerType :: Typeable a = IO
in this respect (other than dogma and superstitious fear about
the evils of global variables :-)
I agree about not wearing a hair-shirt, but how do you propose to solve
the multiple import problem: B imports A, C imports A, D imports B C.
Now the top level inits (a - computation) in A, do they happen once
On Thursday 11 Nov 2004 6:36 am, Judah Jacobson wrote:
AFAIKS, the definition of once that I gave uses unsafePerformIO in a
perfectly sound manner; namely, the creation of a top-level MVar. It
only becomes unsafe if certain optimizations are performed; but
then, that's also true for the
Graham Klyne wrote:
Keean,
As far as I can tell, both your solutions to the one-shot problem
require that:
(a) the expression to be one-shotted is in the IO monad. That seems
reasonable, since why else does one care (semantically speaking)?
(b) they depend on the host operating system
At 11:31 11/11/04 +, Keean Schupke wrote:
Wouldn't it be easier to simply define once as a common Haskell library
function?
Erm, it is a library function (I provided the NamedSem library as an
attachment)... Are you suggesting it would be nice to be able to do this
without talking to the
Graham Klyne wrote:
Wouldn't it be easier to simply define once as a common Haskell
library function?
Depends on the type and the expected semantics. As Adrian Hey already
pointed out, (once :: IO a - IO a) with the obvious semantics is never
going to be safe, because it's just not the case
At 12:27 11/11/04 +, Ben Rudiak-Gould wrote:
Graham Klyne wrote:
Wouldn't it be easier to simply define once as a common Haskell library
function?
Depends on the type and the expected semantics. As Adrian Hey already
pointed out, (once :: IO a - IO a) with the obvious semantics is never
On Thu, 11 Nov 2004 09:16:04 +, Adrian Hey [EMAIL PROTECTED] wrote:
That's the trouble with unsafePerformIO. Haskell is supposed to be a
purely functional language and the compiler will assume all functions
are pure. As soon as you use unsafePerformIO to create something that
isn't a
Graham Klyne wrote:
At 12:27 11/11/04 +, Ben Rudiak-Gould wrote:
[..]
going to be safe, because it's just not the case that
x = once (newIORef ())
y = x
has the same intended meaning as
x = once (newIORef ())
y = once (newIORef ())
No amount of
On Thu, 11 Nov 2004 12:27:17 +, Ben Rudiak-Gould
[EMAIL PROTECTED] wrote:
On the other hand, these are perfectly safe:
once' :: IO a - IO (IO a)
oncePerString :: String - IO a - IO a
oncePerType :: Typeable a = IO a - IO a
once' seems virtually useless unless you have
I think you are right... The only safe operation I can see for a
one-time init
is type IO (). All results have to be returned via side effects. Hence with
my named-MVar proposal the first execution of the init function initialises
certain named-MVars, and subsequent executions do nothing at all.
On Thu, 11 Nov 2004 20:14:24 +, Keean Schupke
[EMAIL PROTECTED] wrote:
I think you are right... The only safe operation I can see for a
one-time init
is type IO (). All results have to be returned via side effects. Hence with
my named-MVar proposal the first execution of the init function
Actually, I don't see anything wrong on the face of it with
oncePerType :: Typeable a = IO a - IO a
since the only instances of Typeable are monomorphic. Indeed, the
implementation seems pretty straightforward: store the results of
already-run computations as Dynamic values in a global
1 - 100 of 164 matches
Mail list logo
