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
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 nam
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) not
At 13:43 29/11/04 -0800, John Meacham wrote:
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
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
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
| > 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 function.
|
| Yes, I have seen this in the code, too. The Ord and Typeable
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 part
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 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 intege
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
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
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 thre
[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 ...
http://www.h
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 dictiona
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
> ass
On Thursday 25 November 2004 10:02, you wrote:
> > 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 a => a
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
> 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 a => a -> IO ()
> getGlobal :: Typeable a => IO a
Your implementatio
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:
>
> http://www
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 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:
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
[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 n
[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
> > pr
> > >The problem is simple enough to restate for anyone who's interested.
> > >"Provide a simple reliable mechanism to ensure that in a given
> > > program run one particular top level IO operation cannot be executed
> > > more than once."
> > No language can guarantee this - all I have to do is r
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
as i said in my other post (waiting for moderator approval), there
are many people on this thread, and i'm not sure they are all talking
about the same thing. perhaps a good step forward would be for
each concrete proposal to go into a separate thread (beginning
with a summary of the use pattern
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
At 10:38 08/11/04 -0800, Iavor S. Diatchki wrote:
It is not (should not be?) the case that IO = ST RealWord, as IO is not a
state monad as we understand it.
In a state monad, the changes to the state are all in the program, i.e.
one can always
point to the part of the program that modified the st
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 libra
> I take it the position of those who object to such things is not..
> "Top level mutable variables are a very very bad thing and
> should never ever be used (Errm..well unless they're really
> necessary, in which case you should use C)."
more like: if you have two parts of your codebase, one
On Monday 08 Nov 2004 9:53 pm, Keean Schupke wrote:
> What did you think of the code example given where the one-shot nature is
> provided by a 'C' wrapper around the FFI function. I think this is the best
> solution...
As a pragmatic solution to this (and only this) particular problem it's OK.
B
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 language
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? Does the creation of global variables never
Yes I didn't read your specification accurately... However I would argue
such a constraint on the problem domain is artificial as operating
systems exist.
At the end of the day it is the job of the OS to manage such one-shot
hardware
inits, not application code. (As the OS is the only thing that
On Monday 08 Nov 2004 6:48 pm, Keean Schupke wrote:
> Adrian Hey wrote:
> >The problem is simple enough to restate for anyone who's interested.
> >"Provide a simple reliable mechanism to ensure that in a given
> > program run one particular top level IO operation cannot be executed
> > more than on
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
_
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 wor
On Monday 08 Nov 2004 12:26 pm, Lennart Augustsson wrote:
> Keean Schupke wrote:
> > Adrian Hey wrote:
> >> The first step to solving a problem is to at least recognise
> >> that it exists. What is "bizarre" is that so many folk seem
> >> to be in denial over this. Perhaps you would like to show
>
On Monday 08 Nov 2004 10:37 am, Keean Schupke wrote:
> Adrian Hey wrote:
> >The first step to solving a problem is to at least recognise
> >that it exists. What is "bizarre" is that so many folk seem
> >to be in denial over this. Perhaps you would like to show
> >me your solution to the "oneShot" p
On Monday 08 Nov 2004 12:14 pm, Lennart Augustsson wrote:
> Adrian Hey wrote:
> > Why are top level IORefs any worse than other IORefs (for
> > example)?
>
> Because global variables are just BAD.
Who said anything about global?
> If you really grok the functional way of doing things there shoul
Just to add a small point... you can see how the 'bad' single context
design affects the code that uses it. Because C allows global variables
it is possible to write libraries that require once-and-only-once
initialisation.
In Haskell (without global variables) it is impossible (or at least
extre
On Monday 08 Nov 2004 11:58 am, Peter Simons wrote:
> Adrian Hey writes:
> > Perhaps you would like to show me your solution to the
> > "oneShot" problem.
>
> I don't see any value in problems that are specifically
> designed so that they can be solved only with a global
> entity.
Why not? Even
Any C library which requires an explicit initialisation call before anything
in that library can be used (common enough IME). Accidental re-initialisation
(e.g. by two independent modules/libraries) will destroy any state currently
be used by the libraries existing "clients".
The need to do this m
Hello,
Just wanted to point out that the suggested idea is not quite correct.
(well that has to be quantiifed a bit, see bellow)
Krasimir Angelov wrote:
--- Ben Rudiak-Gould
<[EMAIL PROTECTED]> wrote:
This is solved by merging the IO and ST monads,
something that ought to
be done anyway:
ty
As a purely practical matter, it seems like the easiest solution (to
this particular use case) is to write a small wrapper initializer in C
which is idempotent, then use FFI to call the wrapper, rather than
calling the initialization directly. This is easy enough to do with a
static local vari
Adrian Hey writes:
> The problem is simple enough to restate for anyone who's interested.
> "Provide a simple reliable mechanism to ensure that in a given
> program run one particular top level IO operation cannot be executed
> more than once."
>
> > Can you give one concrete example of an "int
Adrian Hey wrote:
The problem is simple enough to restate for anyone who's interested.
"Provide a simple reliable mechanism to ensure that in a given
program run one particular top level IO operation cannot be executed
more than once."
No language can guarantee this - all I have to do is run 2
On Monday 08 Nov 2004 3:57 pm, Keith Wansbrough wrote:
> [posted to haskell-cafe per SLPJ's request]
>
> Hi Adrian,
>
> > I can assure you that for the intended applications of oneShot it
> > is vital that realInit is executed once at most, but the user must
>
> [..]
>
> > So please, no more handwa
[posted to haskell-cafe per SLPJ's request]
Hi Adrian,
> I can assure you that for the intended applications of oneShot it
> is vital that realInit is executed once at most, but the user must
[..]
> So please, no more handwaving arguments about this kind of thing
> being unnecessary, bad programm
On 8 Nov 2004, at 12:23, Lennart Augustsson wrote:
Adrian Hey wrote:
4- They already exist (stdin,stout,stderr) and I don't
recall anybody ever complaining about this.
stdin, stdout, and stderr are not global variables.
They are just handles. One possible implementation
of handles is as an Int.
Jules Bean wrote:
Yes... a lot of the example we have seen here are 'just' handles.
newIORef creates handles. Something many programmers would like is the
ability to create fresh handles at the toplevel...
Yes, I hear what they want. That doesn't mean I think it's
a good idea. Top level things
Keean Schupke wrote:
Adrian Hey wrote:
The first step to solving a problem is to at least recognise
that it exists. What is "bizarre" is that so many folk seem
to be in denial over this. Perhaps you would like to show
me your solution to the "oneShot" problem.
Why are you unable to give a concre
Adrian Hey wrote:
4- They already exist (stdin,stout,stderr) and I don't
recall anybody ever complaining about this.
stdin, stdout, and stderr are not global variables.
They are just handles. One possible implementation
of handles is as an Int. So stdin is no more a global
variable than 0. Of
Adrian Hey wrote:
Why are top level IORefs any worse than other IORefs (for
example)?
Because global variables are just BAD. They have been considered
bad a long time, it's not a Haskell thing.
If you really grok the functional way of doing things there should
be *very*, *very* few times you need
Adrian Hey writes:
> Perhaps you would like to show me your solution to the
> "oneShot" problem.
I don't see any value in problems that are specifically
designed so that they can be solved only with a global
entity. What is the real-world application for oneShot?
> If this is such a wacky id
Adrian Hey wrote:
The first step to solving a problem is to at least recognise
that it exists. What is "bizarre" is that so many folk seem
to be in denial over this. Perhaps you would like to show
me your solution to the "oneShot" problem.
Why are you unable to give a concrete real world
example
On Monday 08 Nov 2004 6:00 am, Peter Simons wrote:
> Frankly, the idea that anyone would want to jump through
> hoops to add them to a purely functional language sounds
> bizarre to me.
The first step to solving a problem is to at least recognise
that it exists. What is "bizarre" is that so many
Peter Simons wrote:
> [Global variables]
Well, to be fair one has to say that they are still quite
popular although people call them "singletons" and other
cute things these days.
> Frankly, the idea that anyone would want to jump through
hoops to add them to a purely functional language sounds
bi
Benjamin Franksen writes:
> Even in C++ using global variables is nowadays generally
> regarded as bad design, especially for libraries.
Well, to be fair one has to say that they are still quite
popular although people call them "singletons" and other
cute things these days. I distinctly rememb
Please, can we confine this discussion to just one mailing list:-)
It started out on [EMAIL PROTECTED] so that's where I'd like
to keep it (at least that's where I will be posting my responses
from now on).
On Sunday 07 Nov 2004 10:38 pm, Keean Schupke wrote:
> >I don't understand the relevance o
[moving to haskell-cafe]
Sorry for the long post.
On Sunday 07 November 2004 22:55, Adrian Hey wrote:
> On Sunday 07 Nov 2004 1:45 pm, Benjamin Franksen wrote:
> > It's a similar advantage as using the IO monad has over allowing
> > arbitrary side-effects in functions: The IO monad gives you a cl
Adrian Hey wrote:
Oh and while we're at it, perhaps one of you could explain what it is
you think is unsafe about the hypothetical top level <- bindings we're
discussing (I've asked this before too, but no answer has been provided).
Are your objections dogmatic, aesthetic, or rational?
Do either of
On Sunday 07 Nov 2004 6:19 pm, Benjamin Franksen wrote:
> On Sunday 07 November 2004 17:41, Keean wrote:
> > I might really want to call the initialisation twice. If you use global
> > variables, the library can only be initialised once... but what if I
> > really want to use the library twice? Wit
I don't understand the relevance of this. In the example I gave
we're not talking about an abstract data structure and the init
function is not stateless.
Well, it works like this, to call any function in your library
you must present a state-type. The only way to get a
state-type would be to c
On Sunday 07 November 2004 17:41, Keean wrote:
> I might really want to call the initialisation twice. If you use global
> variables, the library can only be initialised once... but what if I
> really want to use the library twice? With the state in a type passed
> between functions, you can have m
I might really want to call the initialisation twice. If you use global
variables, the library can only be initialised once... but what if I
really want to use the library twice? With the state in a type passed
between functions, you can have multiple different states active
at once.
Keean.
Benj
Jon Cast writes
>I, personally, haven't written a program whose bulk will fit in a single
>file in several years, and I doubt I ever will again. So, support for
>separate compilation is a necessity. How do you intend to handle this?
Hmm; good point.
I see I have been guilty of a careless, unc
G'day all.
On Wed, Feb 05, 2003 at 09:28:05PM -0600, Jon Cast wrote:
> I think I see what you're saying. I still maintain, however, that,
> since you've changed the type of B.b (admittedly implicitly), and B.b is
> exported from B, that you've changed B's interface.
>
> There is a reason make i
Andrew J Bromage <[EMAIL PROTECTED]> wrote:
> G'day all.
> On Wed, Feb 05, 2003 at 08:05:56PM -0600, Jon Cast wrote:
> > I'm not sure I follow this. If you change the type of a value exported
> > from a given module, that's a public change, no? And if you don't, why
> > should re-compilation be
G'day all.
On Wed, Feb 05, 2003 at 08:05:56PM -0600, Jon Cast wrote:
> I'm not sure I follow this. If you change the type of a value exported
> from a given module, that's a public change, no? And if you don't, why
> should re-compilation be needed?
Consider this:
<<
module A where
import B
Andrew J Bromage <[EMAIL PROTECTED]> wrote:
> G'day all.
> On Wed, Feb 05, 2003 at 04:16:33PM -0800, Iavor S. Diatchki wrote:
> > why do you think separate compilation is difficult to achieve in
> > Haskell 98?
> Because of type inference over recursive module imports. Determining
> the type of
G'day all.
I noticed a mistake.
On Thu, Feb 06, 2003 at 11:42:21AM +1100, Andrew J Bromage wrote:
> Because of type inference over recursive module imports.
I meant to say _transitive_ module imports, which includes recursive
module imports.
Cheers,
Andrew Bromage
_
G'day all.
On Wed, Feb 05, 2003 at 04:16:33PM -0800, Iavor S. Diatchki wrote:
> why do you think separate compilation is difficult to achieve in Haskell
> 98?
Because of type inference over recursive module imports. Determining
the type of a function may, in general, require inferring types fr
hello,
Andrew J Bromage wrote:
...
What H98 does is it defines a language for which separate compilation
is at best extremely difficult and at worst virtually impossible
without extra information which is not part of H98 (such as GHC's
hi-boot files).
> ...
why do you think separate compilation
G'day.
On 05-Feb-2003, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> > H98 has nothing to say about the separate compilation; it's an issue for
> > the implementation.
H98 indeed says nothing about separate compilation, and it is indeed
an issue for the implementation.
What H98 does is it def
On 05-Feb-2003, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>
> | Haskell 98 has never supported separate compilation. That's why we
> | have hi-boot files (or something similar).
> |
> | So, yes, I'd like to know how the language designers intend to support
> | separate compilation in the nex
| Haskell 98 has never supported separate compilation. That's why we
| have hi-boot files (or something similar).
|
| So, yes, I'd like to know how the language designers intend to support
| separate compilation in the next version.
H98 has nothing to say about the separate compilation; it's an
G'day all.
On Mon, Feb 03, 2003 at 03:24:49PM -0600, Jon Cast wrote:
> I, personally, haven't written a program whose bulk will fit in a single
> file in several years, and I doubt I ever will again. So, support for
> separate compilation is a necessity. How do you intend to handle this?
Haske
Richard Uhtenwoldt wrote:
> (2) the global variable has a lexical scope that extends over
> the bulk of the program.
> It strikes me as a simple and obvious application of lexical
> scope, and I am surprised that it received no mention in the
> discussions on this list and in Hughes's paper.
Som
Richard Uhtenwoldt <[EMAIL PROTECTED]> wrote:
> I do not think it is nice: I do not like any of the solutions Hughes
> considers in that paper because this problem can be handled much more
> simply with lexical scope and the IO monad.
can be /= should be
> Just to get our bearings, let us first
Richard Uhtenwoldt writes:
:
| The solution I prefer replaces that last with
|
| >main=do
| >globalVar<-newIORef 0
| >let
| >foo = fff aaa bbb ccc
| >bar = ggg xxx yyy zzz
| >mmm >> nnn >> ooo
:
| Am I the only one who prefers the above "lexical scope" solut
Andrew J Bromage writes:
>> John Hughes wrote a nice pearl on the subject, see
>>
>> http://www.math.chalmers.se/~rjmh/Globals.ps
>
>Nice!
I do not think it is nice: I do not like any of the
solutions Hughes considers in that paper because this
problem can be handled much more simply with
Fergus Henderson <[EMAIL PROTECTED]> wrote:
> On 02-Feb-2003, Jon Cast <[EMAIL PROTECTED]> wrote:
> > Claus Reinke <[EMAIL PROTECTED]> wrote:
> > > It is the programmer's responsibility to verify that none of these
> > > problems matter in the particular case of usage. Since many
> > > advances in
On 02-Feb-2003, Jon Cast <[EMAIL PROTECTED]> wrote:
> Claus Reinke <[EMAIL PROTECTED]> wrote:
> > It is the programmer's responsibility to verify that none of these
> > problems matter in the particular case of usage. Since many advances
> > in compiler technology tend to invalidate those verificat
Claus Reinke <[EMAIL PROTECTED]> wrote:
> > > > import IORef
> > > > import IOExts
> > > >
> > > > globalVar :: IORef Int
> > > > globalVar = unsafePerformIO $ newIORef 0
> > > John Hughes wrote a nice pearl on the subject, see
> > > http://www.math.chalmers.se/~rjmh/Globals.ps
> > This paper cl
Andrew J Bromage <[EMAIL PROTECTED]> wrote:
> G'day all.
> On Fri, Jan 31, 2003 at 01:54:26PM -0600, Jon Cast wrote:
> > Otherwise, though, see my other post on this subject:
> > unsafePerformIO will perform its action when the variable is
> > accessed, so you can't write a Haskell program which
Patrik Jansson <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Jan 2003, Jon Cast wrote:
> > Otherwise, though, see my other post on this subject:
> > unsafePerformIO will perform its action when the variable is
> > accessed, so you can't write a Haskell program which differentiates
> > between what any co
G'day all.
On Fri, Jan 31, 2003 at 01:54:26PM -0600, Jon Cast wrote:
> Otherwise, though, see my other post on this subject: unsafePerformIO
> will perform its action when the variable is accessed, so you can't
> write a Haskell program which differentiates between what any compiler
> actually do
G'day all.
On Fri, Jan 31, 2003 at 09:08:22AM +0100, Ralf Hinze wrote:
> John Hughes wrote a nice pearl on the subject, see
>
> http://www.math.chalmers.se/~rjmh/Globals.ps
Nice! Why isn't RefMonad in hslibs?
Possibly because of the class signature:
class Monad m => RefMonad m
> > > import IORef
> > > import IOExts
> > >
> > > globalVar :: IORef Int
> > > globalVar = unsafePerformIO $ newIORef 0
> > John Hughes wrote a nice pearl on the subject, see
>
> > http://www.math.chalmers.se/~rjmh/Globals.ps
>
> This paper claims ``unsafePerformIO is unsafe''. That's not act
On Fri, 31 Jan 2003, Jon Cast wrote:
> Otherwise, though, see my other post on this subject: unsafePerformIO
> will perform its action when the variable is accessed, so you can't
> write a Haskell program which differentiates between what any compiler
> actually does and running the variable alloca
Nick Name <[EMAIL PROTECTED]> wrote:
> On Fri, 31 Jan 2003 07:47:43 +
> Glynn Clements <[EMAIL PROTECTED]> wrote:
> > The usual fudge is:
> > import IORef
> > import IOExts
> > globalVar :: IORef Int
> > globalVar = unsafePerformIO $ newIORef 0
> I see in the documentation
Ralf Hinze <[EMAIL PROTECTED]> wrote:
> > Pavel G. Zhbanov wrote:
> > > Is it even possible to make a "global variable" in Haskell? If
> > > yes, how?
> > The usual fudge is:
> > import IORef
> > import IOExts
> >
> > globalVar :: IORef Int
> > globalVar = unsafePerformIO $ newIO
Glynn Clements <[EMAIL PROTECTED]> wrote:
> Pavel G. Zhbanov wrote:
> > Is it even possible to make a "global variable" in Haskell? If yes,
> > how?
> The usual fudge is:
> import IORef
> import IOExts
> globalVar :: IORef Int
> globalVar = unsafePerformIO $ newIORef 0
On Fri, 31 Jan 2003 07:47:43 +
Glynn Clements <[EMAIL PROTECTED]> wrote:
> The usual fudge is:
>
> import IORef
> import IOExts
>
> globalVar :: IORef Int
> globalVar = unsafePerformIO $ newIORef 0
I see in the documentation of unsafePerformIO that no one make
> Hello,
> Is it even possible to make a "global variable" in Haskell?
> If yes, how?
> Thanks.
(short answer, no time now...)
Look here:
http://www.haskell.org/pipermail/haskell-cafe/2002-January/002589.html
Hope it helps ;)
J.A.
___
Haskell-Cafe mai
> Pavel G. Zhbanov wrote:
> > Is it even possible to make a "global variable" in Haskell?
> > If yes, how?
>
> The usual fudge is:
>
> import IORef
> import IOExts
>
> globalVar :: IORef Int
> globalVar = unsafePerformIO $ newIORef 0
>
> However, beware of creating more than
Pavel G. Zhbanov wrote:
> Is it even possible to make a "global variable" in Haskell?
> If yes, how?
The usual fudge is:
import IORef
import IOExts
globalVar :: IORef Int
globalVar = unsafePerformIO $ newIORef 0
However, beware of creating more than on
100 matches
Mail list logo
