Re: public comment on fortran 2008

Dan Nagle <dannagle@xxxxxxxxxxx> wrote:

Hello,

On 2008-07-02 18:35:33 -0400, nospam@xxxxxxxxxxxxx (Richard Maine) said:

1. The f2003 standard is a failure. In that case the committee should be
studying and addressing the reasons for the failure instead of just
pressing on.

It's not a failure, it's simply true that too few resources
are being spent to implement f03 compilers.

Yeah. I don't actually think it is a failure either. I just mention this
as the alternate interpretation to the one I think more accurate, which
is...

2. It is just too early to expect full implementations of something as
large as f2003. In that case, it is also too early to be proposing a
follow-on standard.

This point was raised at the London meeting (last August).
Van produced a quick count to show that of 45(?) new
features of f08, only 43(?) were dependent *in any way*
on a feature of f03. IOW, f08 is largely a modification of f95,
not a modification of f03.

This claim is simply, in the main at least, false,
and has been largely been shown to be so.

That sounds largely no-responsive to me. It doesn't much matter whether
the features depend on f2003 ones or not. I don't recall my comment as
saying anything even vaguely related to that, so I don't see how the
refutation of some claim that I didn't make is responsive. The f2003
features haven't yet been implemented, yet more features are being
added. That's not going to speed up f2003 implementation. It might well
convince vendors that there isn't much point in releasing an f2003
compiler at all.

I also think there must be a typo or something in the above figures,
because 43/45 sounds like about 98%, which is to say "almost all", which
seems like the opposite of the point being made. Maybe those numbers
weren't the ones that weren't with the point, or maybe it is just plain
a typo. But in any case...

The point largely agrees with my feeling - that the proposed f2008
standard isn't doing much of anything to address the issues with f2003,
as I think it *SHOULD* be. That's what I think the next standard should
be about - addressing shortcommings in f2003 instead of doing a bunch of
unrelated things. I know there are shortcommings in f2003. There are
just bound to be with as big a change as it was. It was too early to get
a good handle on those shortcommings, so the committee went and started
doing other things.

That's actually related to why I stopped going to meetings. Ok, it isn't
the biggest reason. The biggest reason was that I had been doing it long
enough and was ready to retire from the job. But a secondary reason was
that I looked at the (too) long list of things people were proposing to
work on for f2008 (too long even after it was cut down to "approved"
items) and saw that this didn't seem like the right thing to be doing to
me. I voiced a bit of that during meetings, but eventually decided that
I didn't want to be spending several years as nothing but a nay-sayer,
which is what I could forsee. Perhaps I needed to just "get out of the
way" for younger folk with newer ideas.

I will not continue this discussion,

That's ok. I wouldn't expect it to be a very productive discussion
anyway. (And I won't turn it into a flame war.)

I also don't really expect my formal comment to have much effect. As
several on the committee have noted before, the standards process is
pretty hard to derail once it starts; at least it is hard to derail for
technical reasons. Last I checked, there wasn't even an option to "just
say no". A "no" vote is supposed to be acompanied by a list of things
that would need to be done to change the vote to "yes". The presumption
is that one has a list of specific problems that need fixing before the
standard is approved. "This isn't a good thing to be doing now" doesn't
fit in the format. Perhaps that has changed, but I bet the difficulty of
derailing the train once it is moving hasn't changed.

The misconceptions-to-facts ratio
is huge. For instance, you don't need inheritance
to implement coarrays.

Someone else must be throwing those misconceptions in. *I* sure didn't
and wouldn't say anything even vaguely like that. I said that there are
not as yet any f2003 compilers. That one might possibly be wrong, as
last I heard, the IBM compiler sounded close (but its one I'm not likely
to have access to in the forseeable future); that's why I qualified my
statement on that.

Other than that, I don't see how anything I said could possibly be a
misconception. It is mostly about matters of policy rather than of fact.
You might not like my proposed policy, but the concept of
"misconception" doesn't apply. Policy disagreement would be more like
it.

I did not and do not claim anything in particular about specific
features. I just note that there are new features, which seems pretty
unassailable. I do claim that the implementation of new features will
take resources - more of that stuff that you commented above is in short
supply. I agree with your comment on that.

In my formal comment, I said zero about whether those new features
depended on anything in f2003, so I'm not sure how that can be a
misconception of mine. I did comment a little about it above in this
reply, but not at all in my formal comment submittal. Sounds like you
are confusing my point with some other arguments that I haven't seen and
might not agree with. Whatever they are, they sound like straw men to me
- either that or darned poor arguments that I don't acknowledge as mine.
No wonder they got dismissed if they were presented with that kind of
basis.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: Ten Commandments for Fortran Programming?
    ... everything in the latest standard quite right, ... almost all such features are, then using the feature is still using the ... If you have reason to stray ...
    (comp.lang.fortran)
  • Re: Negative Zero (was Re: Rfd: floating point truncation)
    ... in functions like ATAN2 - without any mention of IEEE. ... they had good reason to do it. ... They thought that these IEEE FP features are a good ... IEEE standard functions, and the additional words. ...
    (comp.lang.forth)
  • Re: file stream open failure reason
    ... >> Is there a standard way to find the reason a file stream open failed ... access rights)? ... That gives absolutely no indication of the reason for the failure. ...
    (comp.lang.cpp)
  • Re: WANTED: Volunteer to Scan Old Programs
    ... BASIC to the American National Standard for Minimal BASIC, ... Implementation-defined features ... Error and exception reporting ... of interpretation, and Section 5 for information peculiar to ...
    (comp.os.cpm)
  • Re: Fortran Features
    ... without a specific list of extensions. ... In order to make the features optional like this, ... will need to be included in the standard. ... means that you get into a substantial debate on each ...
    (comp.lang.fortran)