Proposal: fixing the 'pure' floating point problem.

Sergey Gromov snake.scaly at gmail.com
Sun Mar 15 17:14:59 PDT 2009


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.



More information about the Digitalmars-d mailing list