IF-BODY (Version 5)

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

I hate to keep beating on this, but we're working on developing internal
procedures for handling controversial cases, and it probably is worth
trying to debug these procedures on a stupid case like this before
something really hard comes along.  I think we've got the wrong model
here for dealing with controversial things.  It is unreasonable to ask
one person to produce a balanced presentation that fairly summarizes all
points of view, including views that he disagrees with.

KMP's latest version of the IF-BODY proposal is a case in point.  It
represents a good-faith attempt on his part to present a balanced
discussion of the issues, but the result is nevertheless unbalanced in
subtle ways toward his point of view.  I'm not trying to dump on KMP
here -- if I had written the summary, I'm sure it would be even more
biased the other way.

KMP states at the outset that some implementations, if allowed to, will
implement this extension, and that these extended implementations will
"typically" not generate a warning.  Later he argues that encouraging
(but not requiring) a warning is inadequate, because an implementation
that adds this feature must think it is a good idea, and you don't warn
about good ideas.  This ignores the possibility of a "warn me about any
non-portable code" compilation mode, which is the right solution
(assuming this IF-BODY problem is troublesome enough that it is worth
fixing at all).  If an implementor doesn't choose to support such a
mode, fine; that's between him and his customers.  But don't ask the
rest of us to mess up the language in order to make that
implementation's users more comfortable -- if the vendor doesn't want to
employ the obvious simple technique for solving this problem, then it
presumably isn't worth solving.  I've stated this view N times before
and this "somebody prepare a summary" process keeps eviscerating the
argument.  Again, it is the process that is at fault, not the people
doing the summarizing.

It seems to me that the process should go something like this: Person X
proposes a compatible extension.  If, after some discussion, consensus
is reached on some (possibly amended) version of the extension, we put
that version forward as a proposal, with some sort of joint rationale in
the discussion section.  If the committee doesn't like the proposal and
can talk the proposer into dropping it, fine, we drop it.  If there is
no consensus in favor of the change, but the proposer wants to present
the matter to the full X3J13, then he should prepare the most persuasive
argument he can muster -- none of this "balance" stuff.  Then, in the
discussion section, the opposition gets to have its say.  The point is
that each side of the case must be argued by someone who believes in it.
Just like the lawyers.  I suppose that in some cases, there might be
more than one dissenting opinion: various people might dislike a
proposal for different reasons.

There remains the question of who gets the last word.  We could iterate
until quiescence or exhaustion is reached, flip a coin, or establish
some arbitrary guideline.  I guess I'd say that the proposer gets his
say, then the negative voices, and finally the proposer gets a short
rebuttal (confining himself to answering what the opposition said,
rather than introducing new arguments).  The result is concatenated, not
summarized, for presentation to the outside world.

The above assumes that the question is whether or not we should adopt
some change.  In a situation where there are N positive proposals to
choose from, all with their advocates, then a FOO:A, FOO:B, FOO:C
approach is appropriate.  The arguments in favor of each position should
be presented by the advocates of that position, if any exist.  In the
case of a yes/no question, it is silly to have separate FOO:YES and
FOO:NO proposals.

-- Scott