Floating point rounding modes: we should restrict them slightly

[Don]

Rainer Deyke wrote:
> Don wrote:
>> The thing you missed is that the non-memoisable pure functions can only
>> read the global state.
> 
> No, I saw that.  But if a (pure) function calls another (pure) function
> that depends on global state, then the first (pure) function also
> depends on global state.
> 
> int global_state;
> 
> pure int f() {
>   return global_state;
> }
> 
> pure int g() {
>   return f();
> }
> 
> int h() {
>   global_state = 5;
>   return g();
> }

Ah. The important thing that makes this work is that the global FP state 
has a clearly defined default. (round-to-nearest, full precision, no 
floating point exceptions enabled). Part of the implicit contract of 
calling a 'memoisable pure' function is that the global FP state is in 
the default state.
No pure function can change the state. So once you're in a memoisable 
pure function, you can safely call any non-memoisable pure function, in 
the knowledge that the default mode is in effect.

> 
>> But you ALWAYS have a choice about that. You can rewrite functions which
>> are independent of locale, or you can pass the locale as a parameter.
>> With floating point, you don't have that option.
> 
> True.  Unless you add functions/operators that use a fixed rounding mode
> to the language.

Yes, there's a few impractical ways it could be made to work (passing 
the rounding mode as an explicit parameter to every function is another 
option).

Actually there's a related issue which I haven't mentioned: the floating 
point exception sticky flags are effectively a global variable, written 
to by every floating point operation which you perform. It can be 
covered in the same way: there's no guarantee that the flags will be 
correct in the presence of memoisation, so you need to be able to 
indicate to the compiler or runtime that the flags returned from this 
function call are important to you.