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