Floating point rounding modes: we should restrict them slightly

[Don]

Rainer Deyke wrote:
> Don wrote:
>> Rainer Deyke wrote:
>>> Don't forget that "uses floating point" is a transitive property.  Any
>>> pure function that calls a pure-but-unmemoisable function is itself
>>> pure-but-unmemoisable.
>> This is incorrect.
> 
> Then I must have misunderstood your proposal.  Either you did a poor job
> of explaining it, or I did a poor job of trying to understand it, or
> it's not as simple as you make it out to be.

> Since I'm not really interested in discussing the details of floating
> point rounding modes and memoisation, I'll just leave it at that.

The description I just gave of it was
The thing you missed is that the non-memoisable pure functions can only 
read the global state.

> 
>>> Is there any real need to treat floating point state differently from
>>> other global state in regard to "pure"?
>> Yes. Because it's all-pervasive.
> 
> It only affects floating point operations.  Other pieces of global state
> (e.g. the global locale) affect other operations. 

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.

BTW, global locales suck, big time. The idea that you can specify the 
formatting in the form of a locale is clearly the creation of someone 
who had never worked in an international environment. (And any locale 
which includes 'currency' is clearly the creation of an idiot).

  Once you make a
> special case for floating point mode, it's easy to argue that the
> special case should be extended to other pieces of global data.

No, because this is a hardware special case. All the other cases can be 
dealt with in software.

> Or maybe I'm completely overthinking this.
> 
>> Unless you treat it specially, you
>> cannot use floating point in any pure function. That creates a
>> restriction which is so severe that 'pure' becomes useless. Something
>> like the following template function could not be pure:
>>
>> T add(T a, T b) { return a + b; }
> 
> In the presence of structs and class executing arbitrary code in opPlus,
> you can't make this pure anyway.  Unless you force opPlus itself to be
> pure, which is almost certainly too restrictive for the current
> definition of pure.

You're right. Bad example. But seriously, people give sqrt(x) as the 
classic example of a pure function.