steve@oakhill.UUCP (steve) (01/04/89)
In article <583@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > > Steve has shown that the USENET can be used to rapidly discover > ambiguities in a language standard. Discussions in this newsgroup > can propose corrective language to eliminate ambiguities from > the standard. The real problem is how to incorporate the new > language in a standard that has been chiseled in stone? Must > we wait for FORTRAN8x? :-( > > After our law makers write and pass laws, the laws appear in a > publication of state or federal statutes. The legislature > will try to correct a discovered flaw or ambiguity in a law > during their next session. In rare cases, a special > session may be called to tackle the problem. Ambiguities in > the law can also be resolved by the courts. All new laws, > recently revised laws and notes of court cases are placed in > the "Cumulative Annual Pocket Part" which is placed in the > back of the appropriate volume of the statutes. > > The purpose of the Fortran ANSI X3.9 1978 standard "is to > promote portability of FORTRAN programs for use on a variety > of data processing systems." The result of Steve's survey > shows that not even a simple double do loop is immune to > ambiguity when tested for horizontal portability. His example > and others (see Fortech Forum, Vol 2 pages 5-6; Fortran > Forum, Vol 4 pages 19-20 and Fortran Forum Vol 6 pages 10-11) > proves that computer language standards need a "Cumulative > Annual Pocket Part." Without it, the hope for a horizontally > portable standard is an exercise in futility. > Ok, I think I proved my point. We have a big hole in our standardization process. And I think the problem is four-fold. 1) We need to come up with a way to create standards that solve our problems. Our current system seems fine, execept see number four below. Many times it seems that standards are started years after people realized there are needs for them. Our current process needs to be more timely. 2) We need a way for ambiguity to be answered in a continual way once the standard is out. If there was such a way, the question of 'Dubious Fortran Construct' could be sent out, evaluated and the unambigous interpretaion answered and published. 3) We need a way to gradually bring a language up to date. These jumps from F66 to F77 to F8x are too jarring. They cause a revolt everytime they happen, wheather the revolt is necessary or not. 4) We need a way to revolt against The Powers That Be (TPTB) when they force on us a standard (or ruling in #2) that is not to our liking. If they issued a ruling that 'Dubious Fortran Construct' was illegal, and most programmers disagreed, a mechanism must be in place to protest. And TPTB that be must be responsive. I think the mechanism is somewhat there, but the responsiveness isn't. OK, I think I've laid some grounds for discussion here. Let's discuss. enough from this mooncalf - Steven P.S. Since I come from a legal family I have no problem with a bi-headed legistrative, judical system. One continuating pulling in new theory and users comments for a new standard every ~18 months, the other head coming up with the interpretations of the standard. Revolts could be settled by having the standard writers address the function in their next standard. Of course the man power and time required for this is out of the question. ---------------------------------------------------------------------------- These opinions aren't necessarily Motorola's or Remora's - but I'd like to think we share some common views. ---------------------------------------------------------------------------- Steven R Weintraub cs.utexas.edu!oakhill!devsys!steve Motorola Inc. Austin, Texas (512) 440-3023 (office) (512) 453-6953 (home) ----------------------------------------------------------------------------
steve@oakhill.UUCP (steve) (01/04/89)
I am sorry for this quickie follow-up but I can not get cancel to work.
An additional P.S. to my last article is that if this dicussion bears any
relevant fruit, we should spread it into other groups to widen the
view-point. It doesn't help anyone if we solve problems if the whole
world ignores us.
enough from this mooncalf - Steven
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub cs.utexas.edu!oakhill!devsys!steve
Motorola Inc. Austin, Texas
(512) 440-3023 (office) (512) 453-6953 (home)
----------------------------------------------------------------------------khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/04/89)
In article <1760@devsys.oakhill.UUCP> steve@oakhill.UUCP (steve) writes: >> claims about the current process not working, copied from >> a previous posting >Ok, I think I proved my point. We have a big hole in our >standardization process. And I think the problem is four-fold. No you proved that the current system is misunderstood. > >1) We need to come up with a way to create standards that solve our > problems. Our current system seems fine, execept see number > four below. Many times it seems that standards are started > years after people realized there are needs for them. Our > current process needs to be more timely. This is often debated. The general consensus has worked out that for large critical fundamental systems, quick change is worse. > >2) We need a way for ambiguity to be answered in a continual way > once the standard is out. If there was such a way, the question > of 'Dubious Fortran Construct' could be sent out, evaluated and > the unambigous interpretaion answered and published. There is. It works. You ask. You write X3J3 and ask for a formal opinion, and you get one. The result is published as part of the formal minutes. Even silly (and patently illegal programs) are accorded formal treatment. > >3) We need a way to gradually bring a language up to date. These jumps > from F66 to F77 to F8x are too jarring. They cause a revolt everytime > they happen, wheather the revolt is necessary or not. F88 is a pure superset of F77 just so this gradual evolution can happen. Interested parties signed up to get the minutes of the meetings and know how much effort went into defining a procedure to gradually remove stuff (over a 20+ year period). It is far from clear to me that you are bring up anything that wasn't discussed (and to a small extent) decided during the last 11 years. > >4) We need a way to revolt against The Powers That Be (TPTB) when they > force on us a standard (or ruling in #2) that is not to our liking. > If they issued a ruling that 'Dubious Fortran Construct' was illegal, and > most programmers disagreed, a mechanism must be in place to protest. > And TPTB that be must be responsive. I think the mechanism is somewhat > there, but the responsiveness isn't. Give an example. I seriously doubt that any formal complaint to X3J3 would be ignored. I personally know of no such case. > >OK, I think I've laid some grounds for discussion here. Let's discuss. > >P.S. Since I come from a legal family I have no problem with a bi-headed >legistrative, judical system. One continuating pulling in new theory and >users comments for a new standard every ~18 months, the other head coming >up with the interpretations of the standard. Revolts could be settled >by having the standard writers address the function in their next standard. >Of course the man power and time required for this is out of the question. I think the legal system is a good example not to copy! 18months is nearly universally held to be much to fast .... typical scientific applications grow over DECADES. If the standard changes every 2 years (allow SOME time for implementation) there will be NO time to ever finish a project...one will spend all of the development time re-certifying the underlying tools! Let's see if I got it right..The points you raise are: 1) We need a body to decide what is legal. We have one. 2) Its work should be published. It is. Just pay for the service, and poof! It's there. 3) There should be a way to protest. There is. Admittedly there is no higher body to appeal to. But there is no evidence (I know of) to indicate that one is needed. 4) There should be more change (std every 18 months!) No. To the best of my knowledge no one has seriously suggested less than 5 years. 10 years was the agreed goal...which has slipped a bit. 5) There should be less change (revolt ?) A lot of deliberation went into the current draft. The reason things are the way they are is because it was felt that a lot of extensions were necessary to the language. Nothing was left out (from f77) because running old decks is felt to be necessary to for evolution. It is very hard for me to see anything to discuss except points 4,5. Clearly these two are closely tied, but since many minor hacks to the standard would not accomplish much (except to tie up development) 10 year gestation times seem to imply "large" changes. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus