Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!olivea!oliveb!veritas!amdcad!sun!boise.Eng.Sun.COM!wsb From: wsb@boise.Eng.Sun.COM (Walt Brainerd) Newsgroups: comp.lang.fortran Subject: Re: Fortran Extended Standard Message-ID: <143690@sun.Eng.Sun.COM> Date: 12 Oct 90 22:07:51 GMT References: <1990Oct9.213414.19147@hamblin.math.byu.edu> <65400@lanl.gov> Sender: news@sun.Eng.Sun.COM Lines: 86 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