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
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
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
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
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
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian Hey wrote:
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
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
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
The trick of controlling allocation of external
resources by using NOINLINE, unsafePerfromIO,
and IORef to create global variables has become
an indispensable technique in Haskell. It seems to
work well enough with most current compilers.
However, it is well known that the semantics of
NOINLINE
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
On 01/02/07, Bulat Ziganshin [EMAIL PROTECTED] 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
I think that's too safe-looking. Anything that translates to something
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
On 2007 Feb 1, at 11:51 AM, David House indited:
On 01/02/07, Bulat Ziganshin [EMAIL PROTECTED] 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
I think that's too
(CCing the list as this is of general concern.)
On 01/02/07, Yitzchak Gale [EMAIL PROTECTED] wrote:
Why is this unsafe? What could go wrong?
It could segfault due to the type safety properties that unsafePerformIO breaks:
import System.IO.Unsafe
import Data.IORef
ref :: IORef [a]
ref -
On Thu, Feb 01, 2007 at 04:51:39PM +, 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:
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
On Wed, Nov 24, 2004 at 08:53:47AM +0100, Lennart Augustsson wrote:
Well, I don't. unsafePerformIO is an extension that is very much
against the spirit of Haskell. Haskell with it does not have the
properties I want. So I don't use it. :)
I hope 'it' means unsafePerformIO, not Haskell :)
I
with the functions implemented by my proposal and without
unsafePerformIO
you can have all the guarantees, but still have global variables. In particular
you can implement most of John Meacham's examples (the Random module),
Data.Unique,
and Caching
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:
Thanks to the encouraging post
http://www.haskell.org//pipermail/haskell/2004-November/014748.html
from Benjamin Franksen, I have implemented
my proposal which allows the user to define new global variables without
unsafePerformIO, NOINLINE and other such horrors.
http://www.haskell.org
George Russell wrote:
(3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
It uses unsafePerformIO which is very much an extension to Haskell. :)
-- Lennart
___
Haskell mailing list
Lennart Augustsson wrote:
George Russell wrote:
(3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
It uses unsafePerformIO which is very much an extension to Haskell. :)
I think by Haskell he means the common language currently
I wrote (snipped):
3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
Lennart Augustsson wrote (snipped):
It uses unsafePerformIO which is very much an extension to Haskell. :)
Ben Rudiak-Gould wrote (snipped):
I think by Haskell
On 23 Nov 2004, at 11:53, George Russell wrote:
I wrote (snipped):
3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
Lennart Augustsson wrote (snipped):
It uses unsafePerformIO which is very much an extension to Haskell.
:)
Ben
1 - 100 of 269 matches
Mail list logo
