(j3.2006) Four IEEE procedures ought to be impure

[Van Snyder]

On Mon, 2008-07-28 at 14:11 -0500, Bill Long wrote:
> 
> Van Snyder wrote:
> > The four IEEE procedures that aren't allowed in DO CONCURRENT 
> > constructs, viz. IEEE_GET_FLAG, IEEE_GET_HALTING_MODE, IEEE_SET_FLAG and 
> > IEEE_SET_HALTING_MODE, either have side effects that are in essence 
> > either change to a global variable or a save variable, or depend upon 
> > one.  As such, they ought to be impure elemental (now that we have that 
> > term).
> >
> >   
> Two not elemental now, but rather "Pure subroutine.".  Probably easier 
> to just remove Pure for those.
> 
> However, that would seem to make a PURE procedure that currently calls 
> one of these routines suddenly non-conforming.   Are you suggesting an 
> Interp that will change F03?

Yeah, I thought about this after I sent the suggestion.  We are
schizophrenic about this.  In CONCURRENT, we don't allow these guys
because they're not really pure (even though we say they are), but we do
allow them to be referenced from pure procedures because procedures save
and restore the IEEE flags, and therefore their impureness doesn't leak
out.

If we make the procedures impure, so we don't need to say anything about
them in 8.1.7.7, we would have to allow them explicitly in 12.7.  Or we
could leave things as is.  Or....

It seems a little odd that we can't invoke these procedures directly
within a CONCURRENT construct, but we can get them invoked by putting
them into a pure procedure.  This wouldn't allow setting the flags in
any meaningful way within an iteration but outside of the pure
procedure, but it would allow inquiring them, so why do we prohibit
IEEE_GET_FLAG at all?  Same for IEEE_GET_HALTING_MODE.

Oddly, IEEE_SET_FLAG is not proscribed by C828 or C829.

This begs the question "what values do IEEE flags (e.g. overflow) have
when a CONCURRENT construct terminates?"  Should IEEE flags be handled
as they are for procedures (14.3p3-5), or should we just say that any
flag that is signaling before the construct starts, or that signals
during any iteration, is signaling at the end?

Digging a little deeper, I notice that IEEE_*_ROUNDING_MODE and
IEEE_*_UNDERFLOW_MODE are impure.  So one can't use pure procedures to
implement interval arithmetic.  After we abandoned incorporating
interval arithmetic as an intrinsic feature of F2003, one of our
mandates was to adjust things so that users could roll their own
efficiently.  To live up to this promise, since 14.4p4 and 14.5p2 say
that the rounding and halting modes are saved and restored, shouldn't we
make these procedures pure?

Van