pmontgom@euphemia.math.ucla.edu (Peter Montgomery) (10/09/90)
I just received an announcement about a two-month public review
of X3.198-199x, Programming Language Fortran Extended. It says in part
"Programming Language Fortran Extended was previously announced for
public review as a replacement for ANSI X3.9-1978, FORTRAN Language
Standard. Since that public review, it has been decided
that the Fortran Extended language will, when approved, be a
companion specification to ANSI X3.9-1978, not a replacement."
Is this a new name for Fortran 8x? If not, does
anyone know 8x features are included here?
Comments must be RECEIVED by December 18, 1990
(just after my final exams ...). The document costs $70
for domestic orders, and is available from Global Engineering
Documents, Inc., 2805 McGraw Ave., Irvine, CA 92714,
(714)261-1455 or (800)854-7179.
[BTW, I received responses to my comments on the
1989 draft of Fortran 8x last week, 10 months after
submitting them. X3J3 agreed with some of the typos I
pointed out, but not on any of my important requests,
such as extending the intrinsic SQRT function to
return the truncated square root of an integer
or adding a new intrinsics to support multiple precision
integer arithmetic.]
--
Peter L. Montgomery
pmontgom@MATH.UCLA.EDU
Department of Mathematics, UCLA, Los Angeles, CA 90024-1555
If I spent as much time on my dissertation as I do reading news, I'd graduate.psmith@convex.com (Presley Smith) (10/09/90)
Fortran Extended is the X3 Project Name for Fortran 90. Fortran 90 is the official name for the old Fortran 8x. This is the next round of public review in the United States. ISO has received the proposed standard and is processing it for approval. Just because ISO approves this standard does not mean that ANSI must adopt it as a U.S. standard. It must be approved in the U.S. in order for it to become an ANSI standard. Everyone has the opportunity to comment again on the proposed standard. FYI
wsb@boise.Eng.Sun.COM (Walt Brainerd) (10/10/90)
In article <502@kaos.MATH.UCLA.EDU>, pmontgom@euphemia.math.ucla.edu (Peter Montgomery) writes: > > I just received an announcement about a two-month public review > of X3.198-199x, Programming Language Fortran Extended. It says in part > > "Programming Language Fortran Extended was previously announced for > public review as a replacement for ANSI X3.9-1978, FORTRAN Language > Standard. Since that public review, it has been decided > that the Fortran Extended language will, when approved, be a > companion specification to ANSI X3.9-1978, not a replacement." > > Is this a new name for Fortran 8x? If not, does > anyone know 8x features are included here? > > Comments must be RECEIVED by December 18, 1990 > (just after my final exams ...). The document costs $70 > for domestic orders, and is available from Global Engineering > Documents, Inc., 2805 McGraw Ave., Irvine, CA 92714, > (714)261-1455 or (800)854-7179. > > If I spent as much time on my dissertation as I do reading news, I'd graduate. My personal advice is to devote most of your time to your dissertation. Here's why: Based on two American reviews and an international review, a revised draft of Fortran 90 is in the balloting process at the highest level in ISO. While all of this has been going on, X3 decided that Fortran 77 should be retained and what has been called Fortran 8x (now Fortran 90) should be an additional standard. They have decided to take the IDENTICAL document that ISO is balloting as Fortran 90, and call it "Fortran Extended". Since this is not replacing Fortran 77 as an American Standard, it must be considered a "new language" (this has nothing to do with how many new features have been added) and must have its own public review. Since, from a practical point of view, this document has been reviewed twice already, ANSI decided that a shorter review would be sufficient and would allow the comments from that review to be incorporated into the US position on the ISO Fortran 90 ballot. The biggest nightmare for users and vendors alike, I think, would be to wind up with an American "Fortran Extended" that is different in any regard whatsoever from the ISO Fortran 90. Though this last review opens up the possibility, most people are working very hard to ensure that it does not happen. So what can you do? IMHO, nobody is willing to consider significant technical changes at this point, such as removing pointers or putting EQUIVALENCE back on the obsolete list. Even minor technical changes, such allowing you to take the square root of 4 (I also have thought it is strange you can do this on your calculator, but not in Fortran) will probably not have much of a chance, even if they represent good ideas. There are two things that would be nice to send in: 1) descriptions of any real bugs you find in the description of the features and 2) your opinion about having Fortran Extended match identically the ISO standard Fortran 90. At this point, it is planned that X3J3 will meet in December right at the end of the ballot period to consider the comments as a part of preparing the US position on the ISO ballot. And even though the final adoption of a US position is voted only by US members, the position is usually based directly on a recommendation from X3J3, in which many people from outside the US participate. This means that if you can get your comments in a little early, they can be processed early, and it will make it easier to do the careful processing of all of them that is mandatory and desirable. I am assuming this makes everything crytal clear! Quiz at 11. -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
halliday@hamblin.math.byu.edu (David Halliday) (10/10/90)
In article <502@kaos.MATH.UCLA.EDU>, pmontgom@euphemia.math.ucla.edu (Peter Montgomery) writes: > > I just received an announcement about a two-month public review > of X3.198-199x, Programming Language Fortran Extended. It says in part > > "Programming Language Fortran Extended was previously announced for > public review as a replacement for ANSI X3.9-1978, FORTRAN Language > Standard. Since that public review, it has been decided > that the Fortran Extended language will, when approved, be a > companion specification to ANSI X3.9-1978, not a replacement." > > Is this a new name for Fortran 8x? If not, does > anyone know 8x features are included here? ``Fortran Extended'' is indeed the name now given to Fortran 90 in the United States by ANSI. However, as I understand it, Fortran 90 will be the name of the international standard. (I personally do not agree with the X3 committee on keeping ``FORTRAN 77'' as a full standard and having ``Fortran 90'' as an extension thereto. I would much rather have ``FORTRAN 77'' as a sanctioned subset of ``Fortran 90''. But what do I know.) > > Comments must be RECEIVED by December 18, 1990 > (just after my final exams ...). The document costs $70 > for domestic orders, and is available from Global Engineering > Documents, Inc., 2805 McGraw Ave., Irvine, CA 92714, > (714)261-1455 or (800)854-7179. > > [BTW, I received responses to my comments on the > 1989 draft of Fortran 8x last week, 10 months after > submitting them. X3J3 agreed with some of the typos I > pointed out, but not on any of my important requests, > such as extending the intrinsic SQRT function to > return the truncated square root of an integer > or adding a new intrinsics to support multiple precision > integer arithmetic.] I just received the responses to my comments today! The worst problem I have is that the standards committee apparently misunderstood some of my ``most important'' comments---I'll have to try again. (The main thing I dislike about the present proposed standard is the machine dependent ``KIND'' numbers, and the UGLY syntax they engender as applied to constants---the proposed standard of 1988 was much better in this regard IMHO.) > > -- > Peter L. Montgomery > pmontgom@MATH.UCLA.EDU > Department of Mathematics, UCLA, Los Angeles, CA 90024-1555 > If I spent as much time on my dissertation as I do reading news, I'd graduate. ME TO.
jlg@lanl.gov (Jim Giles) (10/11/90)
From article <1990Oct9.213414.19147@hamblin.math.byu.edu>, by halliday@hamblin.math.byu.edu (David Halliday): > [...] > I just received the responses to my comments today! The worst problem > I have is that the standards committee apparently misunderstood some of my > ``most important'' comments---I'll have to try again. (The main thing I > dislike about the present proposed standard is the machine dependent > ``KIND'' numbers, and the UGLY syntax they engender as applied to > constants---the proposed standard of 1988 was much better in this regard > IMHO.) Yes, a friend of mine calls KIND: "the anti-portability feature". I agree. As most readers of this newsgroup will probably recall, my major complaint about the proposed standard is the 'pointer-to-array-slice' feature. It gives no additional functionality - it's just a simple form of syntactic sugar. Now, I have no a priori objection to syntactic sugar, so long as it's free. But, this proposal inhibits optimization by introducing aliasing unnecessarily where it's used. The TARGET attribute limits the damage, but doesn't come close to eliminating it. I haven't received the responses to my comments yet. I already know that they were ignored. I expect them not to be directly answered either. That's what the responses to the first public review did - most of the 'answers' were of the form "the committee chose not to do that". I could tell that much from reading the new proposals. What the public review responses should contain is sensible explanations of _why_ the committee chose to do what it did. It's hard to imagine technical justifications for a number of the things that the committee has chosen to do. Oh well, one more round. I don't suppose they'll listen this time either - nor explain why they didn't. J. Giles
wsb@boise.Eng.Sun.COM (Walt Brainerd) (10/13/90)
In article <65400@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > > Yes, a friend of mine calls KIND: "the anti-portability feature". > I agree. The new kind feature allows you to write a portable standard program that declares a real variable X to have the minimum precision representing values that will hold at least 12 decimal digits, for example. This was not possible in Fortran 77, so this is "pro-portability". The feature settled on makes it a little less convenient for the programmer than a feature that was in an earlier draft, and (like many other features in many other languages) does provide ways to do things that are NOT portable. As the rep from Los Alamos has argued often, I believe, the programmer should be given the tools to do the job, even if some allow "shooting of one's self in the foot". This seems to be the "Fortran way". The way to do the above portably is: INTEGER, PARAMETER :: MY_KIND = SELECTED_REAL_KIND (12) ! Above line should be in a module so it is only necessary once ! REAL (KIND = MY_KIND) :: X . . . X = 0.123456789012_MY_KIND The way to shoot yourself in the foot is to use absolute KIND values: REAL (KIND=4) :: X > I haven't received the responses to my comments yet. I already > know that they were ignored. I expect them not to be directly > answered either. . . . Strange choice of wording. If a response is generated, then obviously the comments were not ignored. What is meant is that the committee did not agree to make the proposed change. > . . . What the public review responses should contain > is sensible explanations of _why_ the committee chose to do what it did. > This sounds reasonable, but let's take a couple of examples that are wildly different. Suppose I suggest that the maximum number of characters in a statement be increased from 2640 to 5280 (go the whole mile :). Suppose the majority of X3J3 thinks 2640 is enough, even though perhaps 5280 is just a good a number. How do you respond indicating WHY? On a really tough one, like adopting Jim's different view of what pointers should be, there are huge amounts of arguments on both sides. It is possible to respond to a request for a change by giving some of the arguments for the other side (such have been given in this news group, for example), but that really does not say WHY the proposal was rejected because there are also many arguments FOR the proposal. As Jim says, it simply comes down to the fact that the "committee chose not to do it". This does not mean that it was not given lots of attention. In short, in many cases, it is not possible to _prove_ to the suggestor, or even _convince_ her/him, that the suggestion should not be adopted. I have been reading some POSIX standards and one nice thing is that there is a large rationale section in some. I used to think this might be a waste of time, but perhaps in the final processing stages, and particularly for those who did not participate in the work of preparing a draft proposed standard, it would save a lot of time and effort. Those that disagree can see what excuses might be offered in advance, so to speak, and perhaps address those issues up front. This is something that should get some discussion now, in case there is a next time for Fortran. > Oh well, one more round. I don't suppose they'll listen this > time either - nor explain why they didn't. I tried to indicate in an earlier posting why people probably are not going to "listen to" (i.e., adopt) changes that have been proposed and argued many times before; it's just getting too late. But as I said, if you find a real bug, it still can be fixed. Obviously, everyone is still free to express opinions; I'm just trying to give you my personal view of where I think things stand. -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991
hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert) (10/13/90)
In article <65400@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >I haven't received the responses to my comments yet. I already >know that they were ignored. I expect them not to be directly >answered either. That's what the responses to the first public >review did - most of the 'answers' were of the form "the committee >chose not to do that". I could tell that much from reading the >new proposals. What the public review responses should contain >is sensible explanations of _why_ the committee chose to do what >it did. It's hard to imagine technical justifications for a number >of the things that the committee has chosen to do. > >Oh well, one more round. I don't suppose they'll listen this >time either - nor explain why they didn't. > >J. Giles I don't know that this will make you any happier, but let me try to explain why responses tend to come out like that: 1. Once the first draft is put out, it takes a 2/3 vote to change _anything_ in it, so all it takes is 1/3 of the committee not to like your suggestion, and it won't happen. They don't have to agree on why they don't like your suggestion. 1/6 of the committee might think it does too much and a 1/6 might think it does too little. All this can make it very difficult for the person assigned to write your response to say anything sensible. 2. It also takes a 2/3 vote to approve your response. This tends to result in responses being very bland, because otherwise too many people on the committee might complain that it doesn't represent their personal point of view and vote against it. The fact that the committee chose not to act on your suggestion is clear. The reason may be contested. 3. The sheer volume of comments works against getting well written responses. Either you end up with a generic response for the subject of your comment, in which case it probably doesn't answer each of your points, or one is specially written for you, in which case the person writing it probably didn't have time to write more than a relatively superficial response. In many cases, this doesn't really do justice to either your original suggestion or the consideration we gave it. 4. On a standard as large as a language standard, the amount of work that goes into creating even the first draft standard is so large that you must have a very strong point (or a lot of people saying the same thing) in order for the committee to accept the work involved in making a change. (You enhance the likelihood of your suggestion be accepted if you can show how to implement your suggestion editorially as well as technically.) If your really want to significantly affect what ends up in a draft language standard, work with the committee informally well before the first draft is released for public consumption. As a practical matter, if you really want to know why a language committee did something, ask an individual on that committee - his or her response is more likely to be what you want than the official response. If you are concerned about bias, ask individuals with opposing points of view and compare the responses. If you really want a committee to seriously consider a suggestion, either visit that committee and sell the idea to them one person at a time, or find a champion on that committee who will do that for you. I had many of the same frustrations as you about X3J3's responses to my comment on FORTRAN 77 when it was a draft standard. That's why I joined the committee for the Fortran 8x (now Fortran 90) work. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications