Floating point rounding modes: we should restrict them slightly

[Don]

Rainer Deyke wrote:
> Don wrote:
>> 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.
> 
> Then I'm not sure it makes to treat "memoisable" as a property of a
> (pure) function.  It seems more like a property of the context from
> which the function is called.  *All* pure function are memoisable if you
> always call them with the floating point rounding mode set to the
> default.  Conversely, all pure functions can be called with an arbitrary
> rounding mode if you treat them an unmemoisable.

That is correct.

> Some function - those that don't perform any floating point calculation,
> directly or indirectly - are independent from floating point state, and
> could even memoised even when called with an arbitrary floating point
> state.  But there is no good way to automatically detect these functions.

It sounds as though you never saw my proposal. My proposal was that, by 
analogy to module(system), specific modules should be marked, for example:
module (advancedfloatingpoint, system) std.math;
or:
module (nondefaultfloat, system) std.math;

All pure functions are memoisable except for pure advancedfloatingpoint 
functions when called from a function (pure or not) which is also in an 
advancedfloatingpoint module.

This is a very tiny hole in the 'purity' rules, and is a tiny addition 
to the language, but it's enough to cover  the practical uses of 
floating-point rounding and exception flags.