- Haskell-Cafe - Haskell.org

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Claus Reinke <claus.reinke(a)talk21.com> 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 claims ``unsafePerformIO is unsafe''. That's not > > actually true in the sense meant; unsafePerformIO merely has safety > > pre-conditions that the compiler can't check. > Which is the main sense in which the 'unsafe' prefix is usually meant > to be interpreted, and that is bad enough (see below, then re-read > John's quote of Simon PJ's description of unsafePerformIO;-). In > particular, the 'unsafe'-prefix is not a hint for the implementation > to treat something with extra care, but a hint for the programmer that > the implementation may shake unsafe expressions around like any other > ones (inlining, cse, ..), even though that is bound to lead to > problems with the hidden side-effects. So you have to be careful. If that weren't what I said, I'd disagree with you :) > 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 verifications, it is > almost impossible to guarantee safety in such cases Even with sufficiently liberal use of {-# NOINLINE #-}? > - about the best one can hope for is to identify and document > precisely which assumptions need to be made to "guarantee" > safety. Unfortunately, this leaves it to users to figure out whether > the assumptions made by 'unsafe' authors (e.g., no inlining) are still > valid at the point of use.. > Btw, when talking about unsafety in that paper, John also happens to > point out the other little problem with unsafePerformIO: it permits to > break type safety (many a good spirit has stumbled over that > "polymorphic references" problem in other functional languages). > > The precondition (proof obligation) of unsafePerformIO is that the > > order in which unsafePerformIOs are performed cannot affect the > > outcome of the program. However, in this case, ordering doesn't > > matter: the only side effect is allocation of a new IORef, and > > IORefs are sufficiently opaque we don't care (or really know) about > > un-allocated IORefs while the only case we care about the > > now-allocated IORef is when we de-reference it. But, that forces > > the IORef, which executes the unsafePerformIO. So, whenever we > > access the variable, it is allocated. Therefore, the outcome of the > > program (regardless of the order of evaluation) is the same as if > > all such global variable declarations are executed before main > > begins executing. So, the outcome is independent of the order of > > evaluation. > > There you go: the precondition of unsafePerformIO is satisfied, so > > the usage is safe. > There you went.. into one of the many available traps in this > mine-field: > You argue that unallocated IORefs don't matter as long as "the" IORef > is allocated before it is dereferenced. But that's just part of the > problem - what about inlining globalVar, creating multiple IORefs? {-# NOINLINE globalVar #-} :) > Remember that, by using unsafePerformIO, you've given the compiler the > license to treat globalVar as an expression without side-effects, and > for those inlining is a common first step to enable further > optimisations (last time I checked, the language report didn't even > guarantee the sharing on which the globalVar trick depends)! Now there > are multiple side-effects instead of a single one, and read-and > write-accesses are spread out over the multiple copies of your IORef, > none of which is likely to hold the value you'd like it to have.. > Cheers, > Claus Jon Cast

2 1

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Andrew J Bromage <ajb(a)spamcop.net> 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 differentiates > > between what any compiler actually does and running the variable > > allocations before main. > As has been pointed out, there is no language requirement for a > Haskell implementation to be "fully lazy". In particular, it is > technically possible for an implementation to garbage collect > globalVar and re-evaluate it on the next call. So, the technique is implementation-dependent. Since Hughes' recommendation is equally non-portable, I don't see this as a serious problem in this case. > Haskell 2 should probably have a pragma controlling this. IMO, that would be a good idea :) > Cheers, > Andrew Bromage

1 0

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Patrik Jansson <patrikj(a)cs.chalmers.se> 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 compiler actually does and running the variable > > allocations before main. > If you initialize this "global variable" with a value from a file > which is changed by main (or over time) then order does matter. 1. Why would you do this? In any case, the solution adopted in C (initialize the global statically with ``no value'' (0, NULL, Nothing, etc.) and overwrite it at a fixed point in main or elsewhere) should be good enough. 2. In any case, my claim is actually: If a :: IO alpha, for monomorphic alpha, and a's only interaction with the state consists of either creating new IORefs or accessing IORefs created by a, then unsafePerformIO's result is unaffected by the order of evaluation. > I claim unsafePerformIO is very often unsafe It's always potentially unsafe. However, it is always possible to prove that a particular application is safe (under sufficiently stringent conditions, of course). > - the question is more like if the "level of unsafety" is acceptable > for a particular application. There is no "level of unsafety". There is only the level of trust you put in your proof of satisfaction of unsafePerformIO's proof obligation and your view of the acceptability of the portability restrictions of your proof. > /Patrik Jon Cast

1 0

RE: Problem with backtracking monad transformer
by Guest, Simon 02 Feb '03

02 Feb '03

Hi, > On Thu, Jan 30, 2003 at 01:55:50PM -0000, Guest, Simon wrote: > > > I'm trying to make a backtracking state monad using Ralf Hinze's > > backtracking monad transformer. My problem is that it > > won't backtrack very far. > > > > Suppose I try ( a >> b ) `mplus` c. > > > > If b fails, it should try c, but it doesn't rewind past a. Andrew Bromage wrote: > > I've compared it with my own > well-tested implementation and it seems identical modulo renamings. The similarity is explained by the fact that I looked at your example on the Haskell Wiki as well as Ralf's paper, so thanks for that useful page. > > In case you want to compare: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hfl/hfl/mtl/ I will have a look at try to see what I am doing wrong. > > I didn't follow the rest of the code, so I suspect the problem is > elsewhere. One place to look is here: > > > -- backtracking state monad > > -- > > type NDSM st a = BACKTR (SM st) a > > You may have meant to stack the monad transformers in a different > order. This bit I don't understand. I only have one monad transformer, which I use to transform my SM monad. I have an uneasy feeling that my observe is in the wrong place (passed to runSM), but again, I can't see what else I should have done. Thanks for the assurance, but I'm still head scratching for now. cheers, Simon

2 1

Re: Global variables?
by Jon Cast 02 Feb '03

02 Feb '03

Nick Name <nick.name(a)inwind.it> wrote: > On Fri, 31 Jan 2003 07:47:43 +0000 > Glynn Clements <glynn.clements(a)virgin.net> 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 makes > guarantees about the order in wich unsafePerformIO arguments are > performed (especially they don't have to be executed BEFORE main), so > this trick should not be adviced as a general practice; it should be > pointed out that it works in GHC but could not work in other > compilers. English nit: I think you mean ``could fail in other compilers'': it's not really impossible for the trick to work in other compilers than GHC. 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 allocations before main. > Vincenzo > -- > Fedeli alla linea, anche quando non c' Quando l'imperatore > malato, quando muore,o dubbioso, o perplesso. Fedeli alla linea > la linea non c'. [CCCP] Jon Cast

3 2

Re: Global variables?
by Jon Cast 02 Feb '03

02 Feb '03

Ralf Hinze <ralf(a)informatik.uni-bonn.de> 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 > > However, beware of creating more than one "global variable" of the > > same type. If you enable optimisation, common subexpression > > elimination may result in both names referring to the same IORef. > 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 actually true in the sense meant; unsafePerformIO merely has safety pre-conditions that the compiler can't check. However, there's nothing wrong with using it (or wrapping it) as long as the preconditions are checked. In fact, IMO, it's /better/ to use unsafePerformIO in a common case like this, because exactly when the preconditions are satisfied will be much better understood. The precondition (proof obligation) of unsafePerformIO is that the order in which unsafePerformIOs are performed cannot affect the outcome of the program. However, in this case, ordering doesn't matter: the only side effect is allocation of a new IORef, and IORefs are sufficiently opaque we don't care (or really know) about un-allocated IORefs while the only case we care about the now-allocated IORef is when we de-reference it. But, that forces the IORef, which executes the unsafePerformIO. So, whenever we access the variable, it is allocated. Therefore, the outcome of the program (regardless of the order of evaluation) is the same as if all such global variable declarations are executed before main begins executing. So, the outcome is independent of the order of evaluation. There you go: the precondition of unsafePerformIO is satisfied, so the usage is safe. > Cheers, Ralf Jon Cast

2 1

how to open a file descriptor
by David Roundy 02 Feb '03

02 Feb '03

Hello. I'm in the process of interfacing with some C code (libcurl), and I thought that the easiest way to transfer the data in (which is a file transfered over the network) would be to open a pipe and write it into the pipe, and then to pass the pipe over to haskell where I could read it with the IO monad normally. Is there any nice way to open up a file descriptor? I was looking at the ghc internal code, which has an openFd function that would do what I want, but it doesn't seem to be exported. :( Any ideas? -- David Roundy http://civet.berkeley.edu/droundy/

2 2

Re: Global variables?
by Jon Cast 31 Jan '03

31 Jan '03

Glynn Clements <glynn.clements(a)virgin.net> 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 > However, beware of creating more than one "global variable" of the > same type. If you enable optimisation, common subexpression > elimination may result in both names referring to the same IORef. Is this true? It seems wrong---I don't think expressions involving unsafePerformIO should be combined, for precisely this reason. Even if it is true, though, the following kludge should work: > {-# NOINLINE mkGlobalVar #-} > mkGlobalVar :: String -> alpha -> IORef alpha > mkGlobalVar name value = usafePerformIO (newIORef value) > globalVar = mkGlobalVar "globalVar" 0 This ensures that no common sub-expression elimination will be performed. > -- > Glynn Clements <glynn.clements(a)virgin.net> Jon Cast

1 0

Now solved [was RE: Problem with backtracking monad transformer]
by Guest, Simon 31 Jan '03

31 Jan '03

Andrew Bromage wrote: > > You may have meant to stack the monad transformers in a different > > order. I finally understand. This was exactly my problem. I had to discard my state monad, and use a state monad transformer on the simple backtracking monad (not the backtracking monad transformer on the state monad). Now it works fine (of course). Thanks for the help. cheers, Simon

1 0

Nine open CSE positions at Chalmers
by Patrik Jansson 31 Jan '03

31 Jan '03

The School of Computer Science and Engineering (at Chalmers Univ. in Gotheburg, Sweden) announces 9 open positions (teaching+research): http://www.cse.chalmers.se/doit/doiteng/vacancies/positions.html Apply or spread the word! (List relevance: Many of us use Haskell both in teaching and in research.) /Patrik PS. From my point of view, Haskellers with a background in Software Engineering / Information systems / Human Computer Interaction etc. are extra welcome!

1 0