问题
In the concurrency library GHC.Conc there is a function called numCapabilities. Its type is numCapabilities :: Int and it actually returns some number you passed by the command line flag (e.g. 5 if the options are +RTS -N 5).
However, getArgs (type: IO [String]) does essentially the same (it returns the unparsed non-runtime arguments) but isn't a pure function.
If the only excuse is that numCapabilities is often needed in pure code, in what way aren't other command line options not needed in pure code?
Am I something missing or is either numCapabilities a design flaw or am I allowed to write the following monster?
myGetArgs = unsafePerformIO getArgs
回答1:
I've seen very varying views on what to do in situations like this. Some think that values that might vary between compiles should not be pure, and some think that as long as a value doesn't change during your program's local run-time (i.e. after some "configuration" has been "set up" in main), it should be pure.
The base package seems to have settled on a middle-ground. numCapabilities will not (as far as I know) change during run-time, but getArgs might.
This is because there is a withArgs function that changes the args you get via getArgs. So, that answers that.
回答2:
Oh dear. If you look at the definition of numCapabilities, you can see it is just:
numCapabilities :: Int
numCapabilities = unsafePerformIO $ getNumCapabilities
and the following ghci sessions illustrate the problem:
[ben@euler ~]$ ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading [...]
ghci> :m +GHC.Conc
ghci> numCapabilities
1
ghci> setNumCapabilities 2
ghci> numCapabilities
1
ghci> :q
Leaving GHCi.
[ben@euler ~]$ ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Loading [...]
ghci> :m +GHC.Conc
ghci> setNumCapabilities 2
ghci> numCapabilities
2
This is definitely bad - the value of numCapabilities depends on when it is evaluated with respect to any setNumCapabilities calls that may exist in your program. Note that in the first session, numCapabilities remained consistent, since the IO is only executed the first time it is evaluated. However, in the presence of inlining (the name isn't marked NOINLINE or anything) even that may not be true - you could in principle get two different values from two occurrences of numCapabilities (although in practice I haven't been able to make this happen).
So the answer is that numCapabilities isn't a pure function, but is erroneously marked as such by the notorious back door of unsafePerformIO.
回答3:
I'd say it's a mistake, but it depends on what one thinks purity is. See the post Notions of purity in Haskell and its discussion. Simply put, the post's argument is that types have meaning, and there is not room in the meaning of Int for something like numCapabilities, which is execution-context-dependent.
回答4:
numCapabilities gives the initial value of getNumCapabilities, wether or not the RTS -N flag argument is present, so the type should be the same.
Have you tried it with a higher number than your computer max. simultaneous threads ?
$ ghci +RTS -N99
GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m +GHC.Conc
Prelude GHC.Conc> numCapabilities
99
Prelude GHC.Conc> getNumCapabilities
99 !!!
来源：https://stackoverflow.com/questions/11851005/why-is-numcapabilities-a-pure-function