Proposal: fixing the 'pure' floating point problem.

Don nospam at nospam.com
Sun Mar 15 12:14:13 PDT 2009


Walter Bright wrote:
> Let's say we have A which is in a floatingpoint module, B which is in a 
> non-floatingpoint module and C which is marked pure in a 
> non-floatingpoint module:
> 
> -------------------------
> module A(floatingpoint);
> void a()
> {
>     set mode;
>     b();
>     restore mode;
> }
> ------------------------
> module B;
> void b()
> {
>     c();
> }
> -------------------------
> module C;
> pure real c()
> {
>     ...
> }
> ------------------------
> 
> 
> Where is the mode for c() getting set back to the default?

A has called a function in B. B is not a floatingpoint module, so b() 
can only be called when the mode is set back to the default. a() 
violates this contract, so a() is incorrect. There's nothing wrong with 
b() or c(). If a() wants to call b(), it needs to restore the mode 
first; or else change b() into another floatingpoint module.

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.




More information about the Digitalmars-d mailing list