Re: [Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers
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 folk seem to be in denial over this. Perhaps you would like to show me your solution to the "oneShot" problem. If this is such a wacky idea then why is the use of the unsafePerformIO hack to do precisely this so common place? I gather it's even used within ghc. If the two Simons don't know how to write "proper" Haskell, what hope is there for the rest of us. Also a few more points that seem to need repeating.. 1- We're talking about the general problem of creating top level "things with identity" (does anyone have a less cumbersome term?) 2- Creating top-level mutable variables (IORefs) is just one utterly trivial use of this capability. 3- Top-level does not imply global. 4- They already exist (stdin,stout,stderr) and I don't recall anybody ever complaining about this. 5- The above are already *implicitly* referenced by many other commonly used top level IO related functions.
But by all means, as long as the compiler extension is disabled per default I won't mind. :-)
No doubt it would be, like all non-standard extensions. But why would it be a problem if it was not? If you don't want to use <- bindings then don't. Nothing else has changed. Regards -- Adrian Hey
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 of why this is necessary then. Even your example of real world hardware that must be initialised once fails! (What if I start two copies of the program?) With this example the only satesfactory solution if for the hardware itself to keep track of when it is initialised. If the hardware has a "I have been inititalsed" flag, the init routine would check this flag as its first action and exit should initialisation already have taken place. Any other solution is broken in a multi-threaded environment (or even a single-threaded one in which multiple exexutions of the same program are possible like DOS). Keean.
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 concrete real world example of why this is necessary then. Even your example of real world hardware that must be initialised once fails! (What if I start two copies of the program?)
Indeed. With hardware the solution is to do hdl <- openDevice which will succeed the first time and then return "busy" until closed. Any access to the device must use the hdl. Trying to do without the handle is just shooting yourself in the foot. It might look good at first, but it doesn't scale. -- Lennart
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 course you need some state associated with the handle, but that state does not have to be a unique global things. You are passing that state around via the IO monad, and there could be multiple versions of it. GHC chooses to implement it differently, but that's a choice. -- Lennart
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. So stdin is no more a global variable than 0. Of course you need some state associated with the handle, but that state does not have to be a unique global things. You are passing that state around via the IO monad, and there could be multiple versions of it. GHC chooses to implement it differently, but that's a choice.
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... Jules
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 with identity are evil. :) -- Lennart
On Monday 08 Nov 2004 12:23 pm, 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.
Isn't an IORef just a "handle" for a mutable variable? They are all top-level TWI's, and I don't see why one form should be regarded as completely acceptable while another should be avoided at all costs. And I don't understand the relevance of your argument about the IO monad. I hope you don't think anybody is suggesting that reading and writing IORefs outside of the IO Monad should be allowed. That is not what this thread is about. Regards -- Adrian Hey
participants (4)
-
Adrian Hey -
Jules Bean -
Keean Schupke -
Lennart Augustsson