Re: those horrible global flags

[David Hough 754R work <754r@xxxxxxxxxxx>]

> we might appreciate suggestions from a
parallel-hardware designer as to what primitives should be provided
to avoid the distributed-flag issues.  The discussions of flags and
modes have been mightily confused 

I think the right way to think about flags is as implicit or explicit
additional results of an individual operation.      Although hardware
implementers naturally fret about how a specification might be implemented,
754 proves that implementable specifications aren't worth much unless
they provide features that languages can standardize and application
programmers can use portably.

The act of accruing all the unrequited flags in some scope,
since some previous event,
should be a separate explicit operation in the source code; that gives
fair warning to the language and hardware, and more importantly, its absence
liberates them.

But I came to the conclusion that that was all too radical a change for
the current working group's mindset, particularly since the proper treatment
of flags, the default exception handling, is rather closely related to
how alternate exception handling might work, and is further complicated by
the subtle distinction between signaling exceptions and raising flags.
There are enough subtleties that nobody could be reasonably certain of 
getting it all right in the time available, and couldn't convince a majority
even if he did.

Some of these thoughts are written down at

http://754r.ucbtest.org/motions/archive/flags.pdf
http://754r.ucbtest.org/subcommittee/flags.pdf