public comment on fortran 2008
in [Fortran]
|
Prev: Fortran numerical server using Com server wizard.
Next: FYI/OT: [Fwd: ANN: Units of measurement for Ada v2.7]
From: Richard Maine on 2 Jul 2008 18:35 Dan Nagle <dannagle(a)verizon.net> wrote: > You may submit a public comment on the committee draft > of the proposed Fortran 2008 standard by sending an email > to f2008-ballot-comments-ext(a)sun.com Just FYI, the following is what I just submitted to that address. This shouldn't be any great shock to those who have read my previous postings here, but I went ahead and made it a formal comment: This is a public comment on the f2008 CD. While I have perused the CD, I have no detailed technical comments at the moment. My only comment is the general one that it is simply too early to be processing the next Fortran standard. I realize that the processing was already somewhat delayed, but insufficiently so in my opinion. To my knowledge, there are no f2003 compilers currently publicly available. I certainly have access to none that implement even a substantial portion of the f2003 standard. I do not think it appropriate to be reviewing a CD for a proposed follow-on standard until there have been multiple f2003 compilers available to the general public for at least a year. A single compiler would provide breadth, both in terms of implementation and user experience. With less than a year of compilers being in user's hands, users have insufficient basis for evaluating what weaknesses in f2003 might need addressing. If the current process continues as scheduled, it appears plausible that there might never be a standard-conforming f2003 compiler during the time frame when the f2003 standard was a current standard. I would interpret that as implying that the f2003 standard was a failure. If so, then it behooves the committee to evaluate the reasons for the failure in order to address them rather than just continuing down the same failed path, adding more features when the existing ones haven't yet been implemented. Even if an f2003 compiler is released between now and the final approval of f2008, I maintain that it would provide insufficient basis for users to evaluate a proposed follow-on language, particularly when that evaluation is required now. Suggesting that user comments can be submitted on the FCD is not, in my opinion adequate response. The FCD is too late in the process for significant decisions about feature selection to be made. Such decisions are more appropriate during preparation and review of the CD. It seems to me that the possible interpretations of the current lack of f2003 compilers fall into one of the following two major categories: 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. 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. Both of those possibilities lead to a common conclusion that this is not an appropriate time to be reviewing a CD for a follow-on standard. I don't think a few months delate will change things either, given my guideline of a year of availability of multiple compilers. I might guess that about 2 years from now might be a more sensible time - for a CD, not for final approval of the standard. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Dan Nagle on 2 Jul 2008 19:32 Hello, On 2008-07-02 18:35:33 -0400, nospam(a)see.signature (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. OTOH, how many f03 C++ compilers (complete!) are there? By most counts I've heard, exactly 1. How many C99 compilers (complete!) are there? Very few. OTOH, there is a complete Ada05 compiler. (The other two Ada compilers are complete Ada95, with Ada05 features.) (FTM, how many complete C# compilers are there? 1) > 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. I will not continue this discussion, unless it takes a completely unforeseen turn. I have been through this many times. The misconceptions-to-facts ratio is huge. For instance, you don't need inheritance to implement coarrays. -- Cheers! Dan Nagle
From: Richard Maine on 2 Jul 2008 20:23 Dan Nagle <dannagle(a)verizon.net> wrote: > Hello, > > On 2008-07-02 18:35:33 -0400, nospam(a)see.signature (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
From: Greg Lindahl on 2 Jul 2008 21:29 On a tangent, there is a way that F03 implementation could have been sped up. In the C++ world there is a company that sells a parser, which is implemented with a good interface for attaching it to compilers. If such a gizmo existed in the Fortran world, I'm sure that many vendors would happily pay to use it, and it would reduce the cost of F03 significantly. Now if gfortran had been farther along already, that probably would have sped things up a bit, through embarrassment. But it wouldn't reduce the implementation cost, except perhaps from some testcase writing. -- greg
From: robert.corbett on 2 Jul 2008 22:20
On Jul 2, 6:29 pm, lind...(a)pbm.com (Greg Lindahl) wrote: > On a tangent, there is a way that F03 implementation could have been > sped up. In the C++ world there is a company that sells a parser, > which is implemented with a good interface for attaching it to > compilers. If such a gizmo existed in the Fortran world, I'm sure that > many vendors would happily pay to use it, and it would reduce the cost > of F03 significantly. > > Now if gfortran had been farther along already, that probably would > have sped things up a bit, through embarrassment. But it wouldn't > reduce the implementation cost, except perhaps from some testcase > writing. Parsing Fortran is trivial. Lexing Fortran is more complicated, but it is a well understood problem. Reducing the time required to write parsers and lexers for Fortran 2003 to zero would not make much of a dent in the total effort needed to create a Fortran 2003 compiler. Bob Corbett |