On Thu, 2008-10-16 at 01:24 +0200, Ariel J. Birnbaum wrote:
On Wednesday 15 October 2008 05:21:04 John Dorsey wrote:
Should all floating point numerals be in the IO Monad?
I'm deviating from the thread's topic, but I tend to agree with this one. Maybe not IO directly, but some kind of STM-style monad, at least (that is, FP operations are composable but ultimately they must be evaluated in IO).
Floating point operations, at least by IEEE754, depend on environmental settings like the current rounding mode. They may modify state, like the sticky bits that indicate an exception occurred. They may jump nonlocally if a trap handler has been enabled.
It is an interesting question: can IEEE floating point be done purely while preserving the essential features. I've not looked very far so I don't know how far people have looked into this before. Haskell currently only supports a subset of the IEEE FP api. One can assume that that's mainly because the native api for the extended features is imperative. But need it be so? Rounding modes sound to me like an implicit parameter. Traps and exception bits sound like the implementation mechanism of a couple standard exception handling strategies. The interesting thing here is that the exception handling strategy is actually an input parameter. So part of the issue is a functional model of the FP api but the other part is what compiler support would be needed to make a functional api efficient. For example if the rounding mode is an implicit parameter to each operation like + - * etc then we need some mechanism to make sure that we don't have to actually set the FP rounding mode before each FP instruction, but only at points where we know it can change, like passing a new value for the implicit parameter, or calling into a thunk that uses FP instructions. There's also the issue that if the Float/Double operations take an implicit parameter, can they actually be instances of Num? Is that allowed? I don't know. Duncan