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 for
On Thu, 17 May 2007, Jason Dagit wrote:
Well, it seems to me that Haskell modules are actually very similar to
singletons. Perhaps all these problems with modules having top level
mutable state could be solved if Haskell modules were parameterizable
at instantiation? I'm not saying we should
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
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
[encouraging everybody to reply on haskell-cafe]
On Tuesday 23 November 2004 12:02, you wrote:
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
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:
[we should really keep this on haskell-cafe because such lengthy discussions
are what the cafe is for]
On Tuesday 23 November 2004 10:26, Adrian Hey wrote:
On Monday 22 Nov 2004 4:03 pm, Benjamin Franksen wrote:
This is getting ridiculous. At least two workable alternatives have been
On Mon, 8 Nov 2004, Keean Schupke wrote:
For 'broken' libraries that cannot support multiple simultaneous
contexts, it would be better to use the 'C' FFI based solution
suggested by another poster. Ideally you would want to find
a library with a better interface - If you tell me the library
Henning Thielemann [EMAIL PROTECTED] writes:
On Mon, 8 Nov 2004, Keean Schupke wrote:
If you tell me the library you wish to use I may be able
to suggest a better alternative.
I'm using FFTW and PLPlot (but not with Haskell), both
uses internal states and thus must be considered as ill
On Tue, 9 Nov 2004, Ferenc Wagner wrote:
Henning Thielemann [EMAIL PROTECTED] writes:
On Mon, 8 Nov 2004, Keean Schupke wrote:
If you tell me the library you wish to use I may be able
to suggest a better alternative.
I'm using FFTW and PLPlot (but not with Haskell), both
uses
Adrian Hey writes:
I don't see any value in problems that are
specifically designed so that they can be solved
only with a global entity.
Even if it was true that I had specifically
designed this problem, it's existance is of some
interest I think.
Perhaps my choice of words wasn't
Quoting Peter Simons [EMAIL PROTECTED]:
Just ask the C++ folks about the
wonders of global variables that are actually complex
classes with a constructor and a destructor.
You can't use that as an argument against global variables
in other languages.
-- Jeff
Quoting Peter Simons [EMAIL PROTECTED]:
jeff writes:
Just ask the C++ folks about the wonders of global
variables that are actually complex classes with a
constructor and a destructor.
You can't use that as an argument against global
variables in other languages.
Why not?
So
16 matches
Mail list logo
