- Haskell-Cafe - Haskell.org

RE: Concurrent-Haskell in GHC
by Simon Peyton-Jones 04 Feb '03

04 Feb '03

| I've started looking into the docs on GHC's | implementation of Concurrent-Haskell, and I got | confused about the architecture. Different sources | seem to indicate that it either: | - Uses one OS thread, and blocking IO calls will | therefore block all the Haskell-threads, or | - Uses one OS thread, occasionaly (50 times a second?) | calling select() to simulate blocking IO calls without | blocking other Haskell-threads, or | - Uses a pool of OS threads so that when a blocking IO | call is made, another thread takes over execution. Basically the last of these. (At least in the most recent GHC.) Simon Marlow implemented a web server using Concurrent Haskell, and has a paper about it too. http://www.haskell.org/~simonmar/bib.html Simon

1 0

Re: Global variables?
by oleg＠pobox.com 04 Feb '03

04 Feb '03

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. Something like that has been mentioned before: http://www.haskell.org/pipermail/haskell-cafe/2002-September/003423.html If the global variables are used to store parameters that are read from configuration files at the beginning and are not changed since, it's possible to make such "global variables" _ordinary_ top-level variables scoped through the entire program. No unsafe operations, no pragmas, no implicit variables, and no reliance on the IO monad for variable access are needed. The previous article said the approach was ugly. I'd like to take it back. The approach relies on an ability to dynamically compile and link in a program -- something that we all do and something that is specifically emphasized in the GHCi documentation. The following code is snipped from the previous article and adjusted for GHC. The latter is used as a meta-evaluator/dynamic linker of sorts. Suppose file '/tmp/a.hs' contains the following user program. Suppose the program needs a global, configurational variable named Config.config_item. >>> File "/tmp/a.hs" > import Config (config_item) > > foo = "foo shows: " ++ (show config_item) > > bar = "bar shows: " ++ (show config_item) > > main = do > print foo > print bar > print foo Realistically a user program would do something more with the global variables than just showing them. We specifically illustrate multiple access to the global variable, to indicate that such access poses no trouble (in contrast to the unsafePerformIO approach). We also note that user computations 'foo' and 'bar' do not have to be annotated with the type and the name of the global variable -- in contrast to the implicit variable approach. Furthermore, foo and bar are pure functions rather than IO actions. The value of the global variable Config.config_item is computed by reading it from the configuration file. The computation occurs before running of the main function of the user program. The following code accomplishes the trick *>>> File "/tmp/b.lhs" *>>> To run this code, do *>>> ghci -package posix b.lhs *>>> Be sure /tmp/config exists and contains an integer value > import System (system, ExitCode(ExitSuccess)) > import Posix(executeFile) > > myconfig_file = "/tmp/config" > > phaseII_var = "/tmp/Config.hs" > phaseII_const = "/tmp/a.hs" > phaseII_eval = "ghc --make " > phaseII_result = "/tmp/a.out" > > nl = "\n" > > writeConfig :: Int -> IO () > writeConfig num = > do > writeFile phaseII_var $ > concat > ["module Config (config_item) where", nl, > "config_item =", show num, nl] > > > runSuperIO () = system (phaseII_eval ++ > phaseII_const ++ " -o " ++ phaseII_result) > >>= \ExitSuccess -> > executeFile phaseII_result False [] Nothing > > main = readFile myconfig_file >>= writeConfig . read >>= runSuperIO We can indeed be sure that the configurational variable is set before the first attempt to access it.

1 0

Concurrent-Haskell in GHC
by Jonathan Holt 03 Feb '03

03 Feb '03

Hi guys! I'm considering doing a server project in Haskell, using GHC, and I'm having the old dilema of trying to figure out the best way of handling multiple concurrent connections: multiplexing or multithreading. I've started looking into the docs on GHC's implementation of Concurrent-Haskell, and I got confused about the architecture. Different sources seem to indicate that it either: - Uses one OS thread, and blocking IO calls will therefore block all the Haskell-threads, or - Uses one OS thread, occasionaly (50 times a second?) calling select() to simulate blocking IO calls without blocking other Haskell-threads, or - Uses a pool of OS threads so that when a blocking IO call is made, another thread takes over execution. So which is right for the current stable GHC? And how efficient/scalable is it? Thanks, -Jony __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

1 0

Global variables?
by pavel＠joker.botik.ru 03 Feb '03

03 Feb '03

Hello, Is it even possible to make a "global variable" in Haskell? If yes, how? Thanks. -- Zhbanov Pavel

8 7

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

03 Feb '03

Fergus Henderson <fjh(a)cs.mu.OZ.AU> wrote: > On 02-Feb-2003, Jon Cast <jcast(a)ou.edu> wrote: > > Claus Reinke <claus.reinke(a)talk21.com> 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 > > > verifications, it is almost impossible to guarantee safety in such > > > cases > > Even with sufficiently liberal use of {-# NOINLINE #-}? > Haskell Report, Appendix E (Compiler Pragmas): "An implementation is > not required to respect any pragma". Right. So perhaps the Haskell Report should take more notice of global variables. But considering that it doesn't, and there is no completely portable mechanism for getting global mutables, it seems to me that bashing any alternative as non-portable is missing the point :) > > > 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 #-} :) > What about creating two copies of globalVar, neither of them inlined? > A compiler could do that to improve performance on some architectures, > e.g. by allowing the function to be called via a short jump > instruction rather than a long jump instruction. See above. > -- > Fergus Henderson <fjh(a)cs.mu.oz.au> | "I have always known that the pursuit > The University of Melbourne | of excellence is a lethal habit" > WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

1 0

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