Walt Brainerd writes:
 > Bob Wells Tel: +44/0 1865 272915 wrote:
 > > Perhaps the wording of the standard should reflect existing
 > > practice more closely rather than create a lawyers dream.
 >
 > I often disagree with this sort of statement in a different
 > context 8^), but it certainly is right on for this situation.
 > 
 > But we all seem to be in violent agreement.

I'm also in violent agreement that this kind of thing should be ok.
What I'm not so sure about is that its worth spending committee
time on.  I seem to recall many hours of debate on exact wording
of this stuff for the standard, with little constructive result.

I do think there is some "brokenness" in the standard in this area,
but I'm not so convinced that the brokenness really matters.

If it were just a question of "should it be right or should it
be left wrong", that one sounds easy to answer.  But when it
turns into "should half of the next meeting be devoted to this
topic", I get quite a different answer.  I know, it doesn't seem
like it should take that much.

This strikes me as *VERY* much like the question of function side
effects.  I recall that you, Walt, made what I thought to be an
excellent presentation on the subject at a J3 meeting Incline Village
several years ago.  If I may grossly summarize, you pointed out that
the standard all but makes function side effects useless.  Functions
can have them, but nothing can ever depend on them.  You pointed out
an f77 interp on this subject.  From a strict viewpoint, the huge
majority of existing Fortran code makes assumptions that aren't really
supported by the standard.  I thought that we should do something
about this, either

  1. Make the standard more explicit on the point.  Not changing the
     meaning, but just giving examples to make the meaning abundantly
     clear.  Its not really that difficult to give such examples.

or

  2. Change the standard.

But in spite of many hours of discussion, the result that came out was
to do nothing.  My interpretation was that the committee as a whole
wasn't willing to write out in black and white an explanation that
almost all existing code made assumptions not supported by the
standard.  But neither did the committee want to change the standard
to make those assumptions valid, because that would mean that some
optimizations couldn't be done.

I think this is broken.  But I finally just gave up on getting it
fixed.  I'd still be in favor of a fix, but I'd not be in favor of
spending the next half meeting working on one.  Because its not
really going to change either what compilers do or how users code.
All it does is change the words in the standard.  And much as I'd
like those words to be a better approximation of reality, there
are limits to how much time I'd invest in it.

If you could arrange to get the wording fixed without taking
significant committee time, I'd be all for it.  I just don't know
whether that's going to happen.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%