- Haskell-Cafe - Haskell.org

Re: Global Variables and IO initializers
by George Russell 29 Nov '04

29 Nov '04

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 particular, I think you can only derive Typeable for a type constructor of type (*). GHC has recently added Typeable1,Typeable2,... which are classes of type constructors of kind *->*, *->*->* and so on, up to 6 arguments I think, and these can be derived, which is a great help. But there are still kinds this does not include; for example (*->*)->*, which is an example of a type constructor I actually used where I wanted an instance of Typeable.

1 0

Execution Contexts
by Benjamin Franksen 29 Nov '04

29 Nov '04

I finally understood that George Russell's Library is not really about global variables. Rather it is about what I want to call 'execution contexts', which are -- as Marcin Kowalczyk observed -- a restricted form of dynamically scoped variables. [NB: Another (maybe better) name would have been 'execution environment' but the name "environment" is too heavily associated with the related concept of process environment (the string to string map given to user processes as an implicit argument).] An execution context is a mutable finite map from types to (monomorphic) values. Each IO action implicitly carries exactly one such map and by default passes it on to the actions that follow. A function is provided to (implicitly) create a new mapping and run a given IO action with the new mapping as its execution context, instead of the default one. [NB: I also understand now why the library uses ThreadIds. This was obscure to me at first because in principle all this has nothing to do with concurrency (beside the requirement that accessing the context should be thread safe). ThreadIds are used simply because they are available as an index and nothing else is. Its just a hack.] Seen this way, the whole thing smells very much of monads. Indeed, the monadic implementation is trivial. I attached a proof-of concept implementation, using George Russel's 'Dict' as an abstract data type in a separate module (copied verbatim from GlobalVariables.hs, see attached file Dict.hs). The idea: we define type Context = MVar Dict and introduce an eXtended version of the IO monad type XIO a = StateT Context IO a together with a small number of simple functions that implement the same interface as the original GlobalVariables.hs; no unsafe operations are used, everything is Haskell98 + Dynamics. Also ThreadIds do not appear and it is not necessary to change forkIO (apart from lifting it, of course). (code is in ExecutionContext.hs) I modified George's test program so that it works with ExecutionContexts. The program is completely isomorphic to the original (and does the same, too ;). The only major difference is that all IO operations are lifted into the XIO monad. Again, almost everything is Haskell98, -fglasgow-exts is only needed to derive Typeable (which can also be done manually). (Code is in TestExecutionContext.hs) The only task that remains to support this programming style so that it can be used practically, is to redefine IO as XIO in the kernel libraries. The annoying liftIOs everywhere (and the necessity to invent higher order lifts along the way) would be gone. I am almost sure that even the trick of indexing the dictionary via types (and thus the dependency on Data.Typeable and ghc extensions) can be avoided with a little more effort. Ben

5 12

Re: [Haskell] Re: Global Variables and IO initializers
by George Russell 27 Nov '04

27 Nov '04

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, but that makes understanding what > a certain part of the program does even harder. How do I find out what > dictionary a write or read to a (no longer global) variable refers to? This seems to me as unnecessary as asking for which memory location it has. Provided the no-longer-global variables act as if they were global within their own universe, there is no problem. The withEmptyDict operator I provide gives you a new universe where everything starts from scratch. It seems to me you have a much bigger problem when you force everything to have global variables, and then want to run multiple copies of a program, only to have them clobber each other's variables. > Furthermore, I have great difficulty in understanding why different threads > need different dictionaries. Could you explain why this is useful, or rather, > more useful than a global single dictionary? Consider Data.Unique implemented over lots of processors. If you had a single IORef managed by a single processor used to generate new unique identifiers, there is the danger that that processor will become a bottleneck for the whole system. Much better to have a thread-local or processor-local IORef which generates new identifiers, which you then prepend with a processor tag. Me (snipped): > It is, but I'm not sure if it can be avoided without using stuff not in > the standard libraries. Ben: > 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 dictionary is big. My implementation is equally inefficient now (because TypeRep's have no Ord), but if TypeRep's had Ord or a hashing function (both would be very easy to provide from GHC's implementation) I could make my implementation efficient very easily, while you'd have to completely rewrite yours to get the same effect.

2 4

Re: Lexically scoped type variables
by oleg＠pobox.com 27 Nov '04

27 Nov '04

Simon Peyton-Jones wrote: > In GHC at present, a separate type signature introduces no scoping. For > example: > f :: forall a. a -> a > f x = (x::a) > would be rejected, because the type signature for 'f' does not make > anything scope over the right-hand side, so (x::a) means (x::forall > a.a), which is ill typed. OTH, `f x = (x::a)' will be accepted if this definition appears in an instance declaration, which mentions the type variable `a' somewhere in its `signature'. Incidentally, Hugs differs from GHC in that matter: Hugs considers type variables in an instance declaration just like type variables in a function signature -- having no effect on the local type variables. One might say that Hugs is more consistent in that matter -- OTH, GHC is more convenient, IMHO. The alternative > 1b) It's brought into scope even if the forall is implicit; e.g. > f :: a -> a > f x = (x::a) would seem therefore consistent with the existing behavior of GHC with respect to `instance signatures'. > 2b) Get rid of result type signatures altogether; instead, > use choice (1a) or (1b), and use a separate type signature We can always emulate the result type signatures: that is, instead of writing foo a :: resType = body we can write foo a = result where result body and use "`asTypeOf` result" wherever we need to refer to resType. Or we can write foo a = result where result = cid result cid (_::resType) = body to reduce the result type signature to the argument type signature. OTH, I have personally used result type signatures on many occasions and found them quite helpful. I would be grateful if there were a way to keep them.

2 1

Re: [Haskell] Real life examples
by Keean Schupke 26 Nov '04

26 Nov '04

I've replied to the cafe, as per requests... Peek and poke are instances of the Storable class, I can re-implement storable, and provide the alternative definition by giving ghc some -i<something> arguments. I don't even need to recompile your module, simply providing the alternate Storable module at link time is sufficient. So I restate my point, it _can_ be done in Haskell as it stands at the moment, and yor proposal would break this. Keean. Adrian Hey wrote: >On Friday 26 Nov 2004 11:39 am, Keean Schupke wrote: > > >>Adrian Hey wrote: >> >> >>>Well it can be written in Haskell, but not using a module that was >>>specifically designed to prevent this. >>> >>> >>Well, It can be written in Haskell as it stands at the moment... >> >> > >No it can't. If I have a device driver that's accessing real hardware >(peeking and poking specific memory locations say), how are you going >to emulate that? You need to make peek and poke parameters of the >module. > >That is certainly possible, but if the author of the driver module >didn't anticipate your emulation needs, you'd be stuck I think. > >Regards >-- >Adrian Hey > > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell > >

2 4

Re: Yet another IO initializer: Effectful declarations and an ACIO monad
by George Russell 26 Nov '04

26 Nov '04

Ian Stark wrote (snipped): > Way back in this thread, Koen Claessen mentioned the idea of a commutative > version of the IO monad for handling things with identity. That doesn't quite > do it, but I have a refinement that might. The thing is to focus on IO > computations that are: > > a) central -- their effect commutes with every other IO action > b) affine -- their effect is not directly observable, and can be discarded. Unfortunately I have a number of examples where I use global variables with initialisation actions which cannot conceivably be proven to be central & affine by the compiler. For example, where I want to call up an external program (such as wish) which I will later use for doing graphics. The Haskell libraries would run into a similar problem when they tried to open stdin/stdout/stderr. Or indeed when they tried to implement RandomGen, which I presume is going to want to get at the system clock to seed the random number generator. My guess is that if we were to have top-level <- actions where the actions were restricted to those certified to be ACIO, it would not be very long before GHC would implement an unsafeForceACIO function ...

3 4

[Haskell] Lexically scoped type variables
by Martin Sulzmann 26 Nov '04

26 Nov '04

Hi, let me answer your questions by comparing what's implemented in Chameleon. (For details see http://www.comp.nus.edu.sg/~sulzmann/chameleon/download/haskell.html#scoped) > ---- QUESTION 1 ----- > > In short, I'm considering adopting the Mondrian/Chameleon rule for GHC. > There are two variations > > 1a) In the example, 'a' is only brought into scope in the > right hand side if there's an explicit 'forall' written by > the programmer > 1b) It's brought into scope even if the forall is implicit; e.g. > f :: a -> a > f x = (x::a) > > I'm inclined to (1a). Coments? > Currently, Chameleon goes for 1b), i.e. foralls are implicit. I agree that 1a) might help the programmer to immediately see which variables are bound by the outer scope. > > ----- QUESTION 2 ------ > > [...] > > The alternatives I can see are > > 2a) Make an arbitrary choice of (A) or (B); GHC currently chooses (B) > 2b) Decide that the scoped type variables arising from pattern > bindings scope only over the right hand side, not over > the body of the let > 2b) Get rid of result type signatures altogether; instead, > use choice (1a) or (1b), and use a separate type signature > instead. > > Opinions? > Chameleon goes for 2c) A Chameleon speciality is that we can write f ::: a->a f x = True f ::: a->a states that f has type a->a for some a. ::: follows the same scoping rules as :: Then, the following statement let f (x::[a],ys) = <rhs> in <body> (I assume that x::[a] states here that x has type [a] for some a) can be encoded as let f ::: ([a],b)->c f (x::[a],ys) = <rhs> in <body> The main motivation behind Chameleon's lexically scoped annotations was to allow for programs such as class Eval a b where eval::a->b f :: Eval a (b,c) => a->b f x = let g :: (b,c) g = eval x in fst g As Josef pointed out, there are also examples where it might be useful that some inner annotations refer to variable a from the outer annotation. Martin

1 0

Re: Global Variables and IO initializers
by George Russell 26 Nov '04

26 Nov '04

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 > assignment. Assignment is still available though. I agree entirely. The fact that declaring global variables using unsafePerformIO introduces an artificial notion of "global" and forces it on every part of the program is a major disadvantage which we haven't heard enough about in this discussion. It prevents you doing all sorts of things. It's bad for parallelism. It prevents you running two independent copies of a (main) action. It prevents you writing a Haskell controller which runs over Haskell actions as subprograms.

1 0

[Haskell] Re: Global Variables and IO initializers
by George Russell 25 Nov '04

25 Nov '04

> 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 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 universe, corresponding to the Haskell program. There shouldn't really be a single "the Haskell program" anyway; imagine something like GHC or an operating system written in Haskell which run sub-systems which require their own global variables. Or imagine a program split between lots of processors where, for efficiency reasons, you don't want everyone to have to refer to the same set of global variables.o > Storing (TypeRep,Dynamic) pairs is redundant, since Dynamics already > contain their own TypeRep (that is how they are made to work). It is, but I'm not sure if it can be avoided without using stuff not in the standard libraries. > I also use a list for the dictionary; and I share your view about > TypeRep badly needing an Ord instance (probably trivial to provide > but I could be wrong). Even better would be a hashable integer. TypeRep actually is implemented internally on GHC using a hashcons'd unique integer, so exposing it should be trivial ...

3 2

Interview with David Roundy on darcs and Haskell
by Josef Svenningsson 25 Nov '04

25 Nov '04

Hi all, At osdir there is a nice interview with David Roundy about darcs, the revision control system written in Haskell. He has a few comments about Haskell as well. Read it here: http://osdir.com/Article2571.phtml This was also covered on /. (which is where I found it). /Josef

1 0