I didn't say NetBSD doesn't use global variables, I said the device
driver model doesn't use global variables.
And quite a few things that used to be in global variables have been
moved into allocated variables and are being passed around instead.
That's simply a better way to structure the code.
I don't don't think global variables should be banned, I just think
they should be severly discouraged.
On Wed, Aug 27, 2008 at 11:25 PM, John Meacham
On Wed, Aug 27, 2008 at 12:17:46PM -0500, Derek Elkins wrote:
On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote:
However, note the weasel words. Those are in there on purpose, every design calls for different solutions. To blanketly say certain constructs are just wrong to the point of disallowing them in the language, especially when they are common practice at the moment, just doesn't seem right.
How can a Haskell user say this? And this is indeed exactly what capability languages do. In fact, this is what almost every language does (for one thing in common practice or another.)
But as a system designer I *need* things like peek/poke/ACIO etc. I am the one implementing 'Random' or 'Data.Unique'. If I have to resort to C code to do such things, that makes haskell unsuitable for a wide variety of systems programming tasks (including implementing the haskell 98 libraries). I know it is certainly possible to do a lot of things in a capability-based system. but you don't always want or have the ability to use such a system.
I am not sure why it was thought netbsd didn't use global state. a simple grep of the kernel headers for '^extern' turns up hundreds of them. even pure capability based systems such as EROS need it for their implementation. What such systems strive for is no or reduced state in their interface. which is a very different thing and also something that I strive for in haskell code. (and is fairly easy to achieve actually)
John
-- John Meacham - ⑆repetae.net⑆john⑈ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe