You may submit a public comment on the committee draft of the proposed Fortran 2008 standard by sending an email to f2008-ballot-comments-...@sun.com
If you are outside the USA, you may prefer to comment through your national body. You are welcome to comment to J3.
The draft may be downloaded from J3's web site at www.j3-fortran.org as 08-007r2.pdf or from WG5's web site at n1723.pdf or from INCITS's web site at pl22.3.incits.org as SC22 N4319.
Public comments may be submitted from 2008 June 6 until 2008 July 6. J3 will act on comments at its August 2008 meeting.
> You may submit a public comment on the committee draft > of the proposed Fortran 2008 standard by sending an email > to f2008-ballot-comments-...@sun.com
> If you are outside the USA, you may prefer to comment > through your national body. You are welcome > to comment to J3.
> The draft may be downloaded from J3's web site > at www.j3-fortran.org as 08-007r2.pdf > or from WG5's web site at n1723.pdf > or from INCITS's web site at pl22.3.incits.org > as SC22 N4319.
> Public comments may be submitted from 2008 June 6 > until 2008 July 6. J3 will act on comments > at its August 2008 meeting.
Would it be better to send several e-mails (one for each topic being commented upon) or a single e-mail containing all one's comments? Perhaps I should first ask if multiple e-mails from the same person are even permitted.
-- J. Giles
"I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
"Simplicity is prerequisite for reliability" -- E. W. Dijkstra
On 2008-06-16 20:12:56 -0400, "James Giles" <jamesgi...@worldnet.att.net> said:
> Would it be better to send several e-mails (one for each topic > being commented upon) or a single e-mail containing all one's > comments? Perhaps I should first ask if multiple e-mails from > the same person are even permitted.
Yes, send as many comments as you want.
It helps J3's internal processing to keep any one comment to one topic, or, for editorial comments, to one clause of the draft.
Dan Nagle <danna...@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-...@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
On 2008-07-02 18:35:33 -0400, nos...@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.
> On 2008-07-02 18:35:33 -0400, nos...@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
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.
On Jul 2, 6:29 pm, lind...@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.
In article <544836a6-751a-4a13-a1bc-a2142c30a...@c19g2000prf.googlegroups.com>,
<robert.corb...@sun.com> wrote: >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.
Yes, but those stuck with front-ends derived from the hard-to-modify Cray FE don't find trivial things trivial to implement. Perhaps you've moved off of it, or rewritten it.
Richard Maine wrote: > 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.
FWIW, the last I checked (last month) I also found the IBM compiler was the furtherest along to full F2003 compliancy with only parameterised derived types still to be implemented in the v11.1 release. I believe the IBM term is "enhanced compliance" :o)
Regarding your point about multiple f2003 compilers being available, for me that is a key issue. Even if the IBM compiler was fully f2003 compliant, I couldn't use their features since nearly all of our other users (i.e. those not using the NCEP supercomputers) wouldn't be able to run the code. We had that issue when we went to full Fortran95 code back in 2003/2004 -- and, as you know, f95 wasn't even that big of a difference from f90. The two things that caused the most headaches were: 1) Usage of NULL() 2) Naming the end statement of interface blocks when overloading.
> FWIW, the last I checked (last month) I also found the IBM compiler was > the furtherest along to full F2003 compliancy with only parameterised > derived types still to be implemented in the v11.1 release.
As far as I know, nobody has yet implemented the parameterized derived type stuff. Maybe that's "still comming." But it does make me wonder whether that feature might be a mistake. Will have to wait a bit more, I suppose, but if it really turns out to be the big stumbling block, then maybe it will need reevaluation.
That would be a pretty major example the kind of thing I was thinking about in terms of f2003 "issues". Mostly, I was thinking about smaller things than that, but if that one turns out to be at issue, it would be a quite major thing.
I say this as one of the people who pushed for PDTs. It seemed to me that they filled a hole. But it is true that they do seem to have complicated interactions with other features. (For example, PDTs do interact strongly with inheritance).
-- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
On Wed, 2 Jul 2008 19:20:45 -0700 (PDT), robert.corb...@sun.com wrote: >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.
I agree completely with what Bob said. Parsing or even lexical analysis is NOT the bottleneck for implementing F2003 features (at least not for us). F03 has major new semantics that have never been seen before in Fortran, which often requires invention or reinvention of intermediate language and code generation, creation of new or revised run-time library routines, rework of existing code to accomodate interactions with new features and much more. Oh, and vendors have to support their existing product too, including bug fixes and performance improvements, which takes resources away from shiny new features.
-- Steve Lionel Developer Products Division Intel Corporation Nashua, NH
nos...@see.signature (Richard Maine) wrote: > >[...] My only comment is > the general one that it is simply too early to be processing the next > Fortran standard. [...] > To my knowledge, there are no f2003 compilers currently publicly > available. [...]users have insufficient basis for evaluating what > weaknesses in f2003 might need addressing. [...]
Richard,
Good luck with this. For what it's worth (not much), this long-time, occasional Fortran programmer shares your views.
Of course, the standards committee is to be commended for keeping the momentum up, rather than waiting too long (as from 77 to 90), but it's hard to understand the logic of finalizing standard N+2 when N+1 has yet to be implemented and tested.
Mike
-- Mike Prager, NOAA, Beaufort, NC Address spam-trapped; remove color to reply. * Opinions expressed are personal and not represented otherwise. * Any use of tradenames does not constitute a NOAA endorsement.
On 2008-07-03 16:21:50 -0400, Michael Prager <Mike.Prager.ind...@noaa.gov> said:
> Of course, the standards committee is to be commended for > keeping the momentum up, rather than waiting too long (as from > 77 to 90),
Thank-you. However, neither WG5 nor J3 can take the credit (although we will, no doubt, take the blame). It's an ISO rule that we must produce updates every five years.
> but it's hard to understand the logic of finalizing > standard N+2 when N+1 has yet to be implemented and tested.
I can't understand this at all.
Fortran 95 had its contents finalized before there were many Fortran 90 compilers, and of those few that there were, most weren't really good enough to tell what the strengths and weaknesses of the underlying *standard* were. Does that make Fortran 95 ill-advised? I don't think so.
Fortran 2008 is 34 pages longer than Fortran 2003 (457 v 423). Of that, a good deal is 14 pages of additional intrinsics. That is, about 40% of what's new in Fortran 2008 is new intrinsics, which, surely, may be judged without experience with Fortran 2003.
Of the rest, some is submodules, which are regarded as repairing a defect in Fortran 90, not Fortran 2003. Does that make Fortran 95 and Fortran 2003 failures? I don't think so.
Of the rest, most is coarrays. Coarrays are a modification of Fortran 95. What part of Fortran 2003 do you need to judge coarrays? I can't think of anything, and a good many smart people have been trying for a long time to think of something, without success.
The rest of what's new in Fortran 2008 is too trivial to need any context for judging (for example, allowing an empty contains part, or "enhancing" the stop statement). Do you really think you need to use a Fortran 2003 compiler to tell if these are good ideas? I don't think so.
I could go on and on. But I'll keep it to just one more example. Pointers, introduced with Fortran 90, have performance weaknesses. These are addressed, to some extent (that the standard really can), by introducing the idea of a contiguous pointer (and a contiguous dummy argument). Does that make Fortran 95 and Fortran 2003 failures because they didn't address these issues? Of course not.
Is the argument that one needs Fortran 2003 to judge Fortran 2008, or that anything "wrong" with Fortran 2003 *must* be fixed in Fortran 2008, and no later revision?
> On 2008-07-03 16:21:50 -0400, Michael Prager > <Mike.Prager.ind...@noaa.gov> said:
>> Of course, the standards committee is to be commended for >> keeping the momentum up, rather than waiting too long (as from >> 77 to 90),
> Thank-you. However, neither WG5 nor J3 can take the credit > (although we will, no doubt, take the blame). It's > an ISO rule that we must produce updates every five years.
There's no rule that every five-year update must contain significant new features. I think the breakneck pace is hurting rather than helping.
-- J. Giles
"I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." -- C. A. R. Hoare
"Simplicity is prerequisite for reliability" -- E. W. Dijkstra
On 2008-07-03 18:35:22 -0400, "James Giles" <jamesgi...@worldnet.att.net> said:
> There's no rule that every five-year update must contain significant > new features. I think the breakneck pace is hurting rather than > helping.
You are correct, and I think that all concerned will agree that I let the new features proposal process get quite out of control this time around.
I can only plead inexperience. Other countries contributed, the largest feature of Fortran 2008 is coarrays, which is a UK proposal. And all was approved by WG5.
Dan Nagle <danna...@verizon.net> wrote: > Fortran 95 had its contents finalized before there were many > Fortran 90 compilers, and of those few that there were, > most weren't really good enough to tell what the strengths > and weaknesses of the underlying *standard* were.
I probably shouldn't have responded further on this. Bringing up f95 is a bit of a sore point with me because f95 is very much like what I would have liked to see for f2008.
Fortran 95 was almost entirely tweaks to problems observed in F90. The biggest part of f95 was just incorporation of the many f90 interp responses. Most of the rest was a very small list of minor features (9 if I recall correctly), the most significant of which were to correct shortcommings observed in f90. All of those 8 were quite small. I've occasionally referred to f95 as f90 release 2; it has more that kind of flavor than of real new version.
Or some might consider f90 to have been a release 0.9 beta, with f95 being the 1.0 :-)
For example, memory leaks were difficult to avoid because of the lack of pointer initialization. That was run into in many places, notoriously in the ISO_VARYING_STRING module, but also in other cases. I recall my very first x3j3 meeting, before I was a member and before f90 had been approved in the US. I was glancing through someone else's copy of the draft varying string proposal during lunch (I didn't have a copy of my own, so I was taking advantage of his copy being temporarily available to me). One of the things I was looking for was to see how it handled memory management because I had seen complications there in some of my own codes and wondered how the "experts" did it. My quick lunchtime glance was enough for me to raise the question "doesn't this leak memory?" It didn't take a very careful study, as there were several allocate statements, but not a single deallocate in the whole thing.
Automatic deallocation of allocatables was perhaps the other "big" thing, though allocatables were still too crippled to be worth much in f95.
I well recall the development process of f95 and how it was dominated by interp work. The very few non-interp features were considered as special-case allowances and were suposed to be restricted to things that were causing problems with f90 codes, even though they weren't exactly errors. Other new features were considered "out of scope", to be deferred to what later became f2003.
I'd say that at least the start of f2003 work (all I was there for) was a pretty big contrast with that of f95. There was a wish-list of one or two hundred proposed new features, which got whittled down a lot, but stil included multiple new features an order of magnitude larger than anything that was new in f95. Interp work got shoved aside to look at the proposed new feature list.
That proposed new feature list was daunting. It almost didn't matter what the nature of the new feature proposals was. Even cursory sorting through a hundred or more of them was enough to shove most other work, including interp work aside. Observing that there weren't a lot of interps to answer turns out to be circular, because one thing it shoved aside was even work on preparing interp requests.
If early f2008 work had been much like that of f95, most of the new feature proposals would have just been put aside as "out of order", since the ground rules didn't allow new features except by special exception.
This deluge of work on new feature proposals for f2008 was after the integration part of f2003 work was already shortchanged by multiple new features that kept being slipped in late in the proccess. Objections to late new features were often met with glib responses to the effect that pretty much anything counted as "integration".
-- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
> On 2008-07-03 16:21:50 -0400, Michael Prager > <Mike.Prager.ind...@noaa.gov> said:
> > Of course, the standards committee is to be commended for > > keeping the momentum up, rather than waiting too long (as from > > 77 to 90),
> Thank-you. However, neither WG5 nor J3 can take the credit > (although we will, no doubt, take the blame). It's > an ISO rule that we must produce updates every five years.
> > but it's hard to understand the logic of finalizing > > standard N+2 when N+1 has yet to be implemented and tested.
> I can't understand this at all.
[...] Well, perhaps I'm not communicating well. My thoughts on this are about logistics rather than language design.
If I were a compiler vendor, I would find the situation difficult, that before I have finished meeting one standard, the next becomes current. It seems rather depressing to work on a difficult product that is already obsolete. However, I am *not* a compiler vendor, so perhaps I am mistaken about this . I won't ask any of them to take a stand here!
As a programmer, one faces a similar situation. Why did I buy a book on F2003?
There are Fortran programmers who find even Fortran 90 too modern. I don't agree with that sentiment, but surely it doesn't serve the user base to have the language always a moving target.
Finally, it seems to me that a useful function of the Fortran after F03 would be to clean up any infelicities instroduced by F03. It will not be possible to know what those are until F03 has had substantial use.
Regards, Mike
P.S. I won't post more on this topic. There is really no point to continue the discussion -- the wheels are in motion.
-- Mike Prager, NOAA, Beaufort, NC Address spam-trapped; remove color to reply. * Opinions expressed are personal and not represented otherwise. * Any use of tradenames does not constitute a NOAA endorsement.
Michael Prager wrote: > Dan Nagle <danna...@verizon.net> wrote:
>> Hello,
>> On 2008-07-03 16:21:50 -0400, Michael Prager >> <Mike.Prager.ind...@noaa.gov> said: >>> Of course, the standards committee is to be commended for >>> keeping the momentum up, rather than waiting too long (as from >>> 77 to 90), >> Thank-you. However, neither WG5 nor J3 can take the credit >> (although we will, no doubt, take the blame). It's >> an ISO rule that we must produce updates every five years.
>>> but it's hard to understand the logic of finalizing >>> standard N+2 when N+1 has yet to be implemented and tested. >> I can't understand this at all.
> [...] > Well, perhaps I'm not communicating well. My thoughts on this > are about logistics rather than language design.
> If I were a compiler vendor, I would find the situation > difficult, that before I have finished meeting one standard, the > next becomes current. It seems rather depressing to work on a > difficult product that is already obsolete. However, I am *not* > a compiler vendor, so perhaps I am mistaken about this . I > won't ask any of them to take a stand here!
> As a programmer, one faces a similar situation. Why did I buy a > book on F2003?
Well, you will undoubtedly get your hands on an f2003 compiler before an f2008 one. I still enjoy programming in f95 even though the standard has been superceded.
> There are Fortran programmers who find even Fortran 90 too > modern. I don't agree with that sentiment, but surely it > doesn't serve the user base to have the language always a moving > target.
Depends on your definition of "moving target", no? With respect to other (more? :o) popular languages, the pace of change of Fortran is positively glacial. e.g., I can download daily builds of some interpreters to get the latest and greatest features that aren't part of the current stable release.
My personal opinion is that because Fortran programmers are, generally, not programmers -- they're scientists, engineers, etc. -- their professional focus tends to be on other things than upgrading to the latest and greatest compiler suite; unlike, say, some startup that is developing commerce applications for deployment on the web where a six-month lag in development tools might make or break them. (I have no idea if that's likely or not, but you get the idea)
> Finally, it seems to me that a useful function of the Fortran > after F03 would be to clean up any infelicities instroduced by > F03. It will not be possible to know what those are until F03 > has had substantial use.
Sure. But, as Dan Nagle pointed out, the process doesn't have to be serial.
> P.S. I won't post more on this topic. There is really no point > to continue the discussion
Oh, I dunno. I enjoy reading other people's opinions on these sorts of things. It's quite apparent that you and Richard have been (or were, in Richard's case) working for the guvmint for far far too long. :oD (just kidding! just kidding! :o)
Michael Prager wrote: > If I were a compiler vendor, I would find the situation > difficult, that before I have finished meeting one standard, the > next becomes current. It seems rather depressing to work on a > difficult product that is already obsolete. However, I am *not* > a compiler vendor, so perhaps I am mistaken about this . I > won't ask any of them to take a stand here!
The depressing thing is when an "important" customer puts in "must conform to Fortran 2003" or even "the current Fortran standard" in their RFP before there are any such products on the market. Heck, we're already getting questions of "do you conform to Fortran 2008?" It's a constant battle of education.
--
Steve Lionel Developer Products Division Intel Corporation Nashua, NH
> Fortran 95 was almost entirely tweaks to problems observed in F90. The > biggest part of f95 was just incorporation of the many f90 interp > responses. Most of the rest was a very small list of minor features (9 > if I recall correctly), the most significant of which were to correct > shortcommings observed in f90. All of those 8 were quite small. I've > occasionally referred to f95 as f90 release 2; it has more that kind of > flavor than of real new version.
Having some experience with the problems compilers encounter with f95 code, I can't see how you can conclude that it's just tweaks to f90.
How about FORALL? The way that was thrown in there as a performance- enhancing feature but turned out to be a total performance dud. Vendors have to support it even so and that can be a distraction from more vital elements of the language.
The ELEMENTAL feature is hard for vendors to get right to this day, but it was made second-rate to the extent that it's illegal to pass a non-intrinsic ELEMENTAL procedure as an actual argument. Of course it's possible to pass an intrinsic ELEMENTAL procedure as an actual argument and invoke it elementally in the callee. This means that vendors still have to support ELEMENTAL dummy arguments even though their primary usage is technically illegal. Also the rules for specification expressions within ELEMENTAL functions are unique to them, which yields another class of expressions which inevitably trips up compilers.
The vast expansion of constant expressions and specification expressions more or less tripled the language right there. Fortunately constant expressions were eliminated in a Corrigendum which left their definition intact but edited out their effect except for the RESHAPE intrinsic which wasn't fixed until f08. Constant expressions more or less got brought back by f03 which liberalized initialization expressions to roughly the point of the original f95 constant expressions.
There were lots of potential tweaks that could have been made such as simply a Note that pointed out what a dumb idea it would be for an implementation to have unnecessarily undefined values in its representation space, or fixing up implementation of numbers which are representable but not model numbers.
-- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
> Having some experience with the problems compilers encounter with f95 > code, I can't see how you can conclude that it's just tweaks to f90.
Because I was involved in doing it? It was quite explicit in the development plan. The plan was described as CC&R, standing for corrections, clarifications, and revisions. That ordering explicitly reflected the priorities. First and second priority went to corrections and clarifications. Those were primarily things from the interp process. Revisions were the lowest priority and were restricted to a list of 9 things. I don't have the list handy at the moment.
One could certainly argue - and apparently you do - that it failed in the plan to be a tweak to f95, but I know first-hand that that was explicitly adopted as the plan.
> How about FORALL?
That was just adoption of the existing HPF standard stuff. The whole of HPF wasn't put into f95, but the parts of it that requires language syntax were. Adding those HPF syntax extensions was one of the 9 non-interp items. I won't debate the wisdom of it; I was never a user of HPF myself, and I don't think much of forall. Elemental was part of the same HPF package.
-- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
Michael Prager wrote: > Dan Nagle <danna...@verizon.net> wrote:
>>Hello,
>>On 2008-07-03 16:21:50 -0400, Michael Prager >><Mike.Prager.ind...@noaa.gov> said:
<snip>
> There are Fortran programmers who find even Fortran 90 too > modern. I don't agree with that sentiment, but surely it > doesn't serve the user base to have the language always a moving > target.
My personal feeling is that if there is a true deficiency or need in the language, it should be addressed by the standard with some urgency. Now whether huge numbers of new features should be incorporated at once is another issue. There should be limits based upon a reasonable survey of vendor resources. It is quite disappointing though, to have to wait ten, fifteen, or twenty years for that one feature that you personnally feel is important.
I can't help feel that the resources applied to the problem set doesn't match task size. If it takes more than four years to update a compiler to a new standard, there is a serious mismatch (I actually think that should be two years).
In message <g4jn3e$dn...@news.nems.noaa.gov>, Paul van Delst <Paul.vanDe...@noaa.gov> writes
>Well, you will undoubtedly get your hands on an f2003 compiler before >an f2008 one. I still enjoy programming in f95 even though the standard >has been superceded.
I'm not so sure. As others pointed out, Fortran 2008 is more of an update to f95 than f2003. Apart from the co-array feature (which may for all I know be very complicated to implement) most of the other features new to f2008 such as the new intrinsic procedures should be fairly easy to add to an existing f95 compiler. Whereas it's pretty clear that implementing the whole of f2003 is pretty difficult.
Clive Page wrote: > In message <g4jn3e$dn...@news.nems.noaa.gov>, Paul van Delst > <Paul.vanDe...@noaa.gov> writes
>> Well, you will undoubtedly get your hands on an f2003 compiler before >> an f2008 one. I still enjoy programming in f95 even though the >> standard has been superceded.
> I'm not so sure. As others pointed out, Fortran 2008 is more of an > update to f95 than f2003. Apart from the co-array feature (which may > for all I know be very complicated to implement) most of the other > features new to f2008 such as the new intrinsic procedures should be > fairly easy to add to an existing f95 compiler. Whereas it's pretty > clear that implementing the whole of f2003 is pretty difficult.
I don't see anything that's more difficult than Ada 95 or C++ and most of the vendors have experience in those languages. I was a bit surprised when Steve Lionel said that some backend(-ish) changes were needed to accommodate some new features as I had thought that they once had a good Ada compiler with similar features, but maybe that was with the DEC/GEM(?) stuff.
