[Haskell-cafe] Monadic Floating Point [was: Linking and unsafePerformIO]

[Ariel J. Birnbaum]

> 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.
Not sure. My doubts are mainly on interference between threads. If a thread 
can keep its FP state changes 'local' then maybe it could be done. I still 
think FP operations should be combined in a monad though --- after all, they 
depend on the evaluation order.

> 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.
Reader? =)

> 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.
This one seems like a tough one to figure. Again, I'd vouch for a solution 
like STM --- composition of FP operations is allowed at a certain level 
(maybe enforcing some settings to remain constant here), while it takes a 
stronger level to connect them to their surroundings. 

> 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.
Technically I guess they could, just like (Num a) => (b->a) can be made
an instance. It would look more like State though, IMO. Or Cont. Doesn't even 
look like Oleg-fu is needed.

Should they? That's a horse of a different colour. There are certain 
properties most programmers come to expect of such instances (regardless of 
whether the Report demands them or not), such as associativity of (+) and 
(==) being an equivalence that break miserably for floating point. 

Floating point is a hairy area for programing in general, but I think it's 
also one where Haskell can shine with an elegant, typesafe model.

-- 
Ariel J. Birnbaum