Proposal: fixing the 'pure' floating point problem.

[Don]

Sergey Gromov wrote:
> Sun, 15 Mar 2009 13:50:07 -0700, Walter Bright wrote:
> 
>> Don wrote:
>>> Something interesting about my proposal is that although it is motivated 
>>> by the purity problem, that's simply a rule for the compiler -- the 
>>> rules for programmers do not involve purity at all.(See my other post). 
>>> Do not call _any_ functions in non-floatingpoint modules (pure or not) 
>>> without restoring the rounding modes back to the default.
>> They could be done in terms of pure - if you call any pure function, the 
>> modes must be set to the default.
> 
> In Don's proposal, the following is legal:
> 
> -------------------------
> module A(floatingpoint);
> pure void a()
> {
>      set mode;
>      b();
>      restore mode;
> }
> ------------------------
> module B(floatingpoint);
> pure void b()
> {
>      do stuff;
> }
> -------------------------
> 
> because, from compiler's perspective, they're
> 
> struct FpuState { mode; sticky; }
> pure FpuState a(FpuState s);
> pure FpuState b(FpuState s);
> 
> and can be actually cached, if compiler so wishes.  IIUC, this is
> exactly the use case when you implement range arithmetics.

Hooray! Someone's understood the proposal.

BTW, I think that probably:
module(lowlevelfloatingpoint) would be better than module(floatingpoint).