gwyn@smoke.BRL.MIL (Doug Gwyn ) (04/04/89)
In article <12975@watdragon.waterloo.edu> tbray@watsol.waterloo.edu (Tim Bray) writes: >In article <9135@alice.UUCP> dmr@alice.UUCP writes: >>Noalias went in, but it went out again. >Why? Inquiring minds not in the standardization community but interested in >optimization want to know. This was explained before (in a C newsgroup, probably not UNIX-WIZARDS), but here goes again, in brief: Why it went in: To provide optimizers a way to know when pointer aliasing was not possible, so they could vectorize etc. to a much higher degree than allowed otherwise. Why it went out: The "noalias" qualification was improperly specified, and consequently spread its influence into internals of C library routines, etc. making a mess that conforming programs would have to contend with. It probably could have been fixed, but there was a big enough stink made about it that it wasn't politically feasible to do otherwise than remove the tainted word "noalias". No other proposal for providing similar function was found acceptable to a 2/3 majority of X3J11.
john@stag.UUCP (John Stanley) (04/11/89)
[Doug Gwyn <gwyn@smoke.BRL.MIL> wrote...] > The "noalias" qualification was improperly specified, and consequently > spread its influence into internals of C library routines, etc. making > a mess that conforming programs would have to contend with. It probably > could have been fixed, but there was a big enough stink made about it > that it wasn't politically feasible to do otherwise than remove the > tainted word "noalias". No other proposal for providing similar > function was found acceptable to a 2/3 majority of X3J11. I still think that one of the primary failings with noailias was the term itself. It's too easy to take a look at "noalias" and have the language center of the brain balk with a [Well, if it isn't an alias, what is it?] type rection. (And the C programmer portion of the brain looks at it and says [What the hell's an "alias"?]) No, that doesn't directly have anything to do with the technical problems it introduced, but a more intuative term would have gone a long way twords making it easier to rectify the problems. A primary, ocassionaly ignored, rule of language design is, avoid defining something in terms of what it isn't... Using a word like "unique" instead would have given a compact explanation of what the qualifier actualy was trying to say, as aposed to "noalias" which was an adhoc term that really doesn't tell you anything at all...... Opinions? --- John Stanley <dynasoft!john@stag.UUCP> Software Consultant / Dynasoft Systems
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/20/89)
In article <1989Oct19.162849.20265@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <742@ccssrv.UUCP> perry@ccssrv.UUCP (Perry Hutchison) writes: >>+ Many of us think "noalias", with the problems in its specification >>+ straightened out, would have been a better solution, but >>+ it wasn't politically feasible to reintroduce such a qualifier. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>In other words, a _technically_ defective hack was put in the standard at >>the last minute, to satisfy someone's _political_ agenda. >Well, yes, but not in the way you meant it. A technically defective hack >("noalias") was indeed put in the standard at the last minute (second public >review) to satisfy someone's (the number crunchers') semi-political agenda. >There was, quite legitimately and properly, a storm of protest from almost >everyone else in sight, including Dennis Ritchie. Partly because the hack >really was technically defective, as written. So it got hastily taken out >again. Something along those lines might indeed have been the best solution, >but it was introduced far too late and without adequate prior thought. If >I am not mistaken, it was also an invention of the committee rather than >proven prior art, which is a big no-no for a standards committee. I'm being proven right in my expressed reluctance to explain all that.. Another way to look at it is that there was a clearly perceived deficiency, and due to time pressure (from many sides) the attempted solution had some flaws in its specification. The whole issue became very political, mainly because Dennis was quite outspoken against the whole notion of type qualifiers. Therefore a technically defective (but repairable) feature was REMOVED at the last minute, leaving a void which had to be covered by some compromise juggling of the type qualifiers we had left. There still is no official support for the kind of improved optimization that "noalias" would have supported. However, "const" is able to signify both "really constant" AND "read only", even though it's stretching the notion a bit to attempt to cover both meanings. In the process, only the first two levels of function parameters were specified so that casts are not necessary to outwit "const" type qualifiers. I believe we got the wording right for that, after many rewrites, and from the experience I'm glad we didn't try to specify this attribute at ALL parameter indirection levels. It was certainly within X3J11's mandate to invent solutions -- when necessary to remedy clearly perceived deficiencies. "Prior art", while important, could not be used as the sole criteria for making decisions. In fact, practically every interesting technical decision in drafting the Standard had good arguments on all sides, and there were a lot of "judgement calls" required after all sides had been heard. If you know some better way to draft such a standard, more power to you. We did the best we could, and I think our consciences are clear.
tneff@bfmny0.UU.NET (Tom Neff) (10/20/89)
In article <11351@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > ... There still >is no official support for the kind of improved optimization that "noalias" >would have supported. ... >It was certainly within X3J11's mandate to invent solutions -- when >necessary to remedy clearly perceived deficiencies. ... I guess the question is whether lack of "official support" for the latest "improved optimization" is really a "clearly perceived deficiency." The whole noalias issue seemed intricately entangled with late 80's notions of addressing and optimization. In five years it will probably look quite silly. At worst, if the concept is that vital it will be introduced in some form as an extension by individual vendors, and if it proves popular and enduring the next committee can add it from "prior art." It is easier for a camel to pass through the eye of a needle than for a standards committee to make up a useful language extension. -- The real problem with SDI is %/ Tom Neff that it doesn't kill anybody. /% tneff@bfmny0.UU.NET
dmr@alice.UUCP (10/21/89)
Bill Plauger first used the phrase "politically impossible" during X3J11's noalias showdown meeting, in May 1988. It's become evident that it is, at least in part, a code for "Dennis won't stand for it." The situation (especially then) was pretty complex. During Dec-Jan 1987-88, Prosser, with help from a central group of X3J11 members and suggestions from me, rewrote the "noalias" paragraphs several times, and the collective wisdom was never able to come up with a proposal that both made sense and was compatible with the design that X3J11 had voted in during the preceding fall. The problem at that point was that this was supposed to be the penultimate draft (only editorial changes), and everyone wanted things to happen as rapidly as possible. The two choices I saw were to try to work something out on my own and present an alternative proposal, or simply to try to rip the thing out altogether. You may think me naive or lacking in self-confidence, but I was genuinely worried that X3J11 would be so impelled to finish things up without another public review that I decided on the second course. The reasoning was that if I said, "I would like you to fiddle the draft in this way," I would be taken less seriously than if I said "Noalias must go. This is non-negotiable." I feared that the committee would decide to go with their previous decision unless I credibly pulled a full tantrum. I decided to handle things this way after talking to several of the insiders on X3J11 who were all somewhat pessimistic of the likelihood that the committee would change its mind (and commit itself to another review). It wasn't a decision taken lightly--I brooded about it throughout early 1988. In retrospect, it seems possible that if I had worked harder and perhaps done more lobbying, it would have been possible to have a "noalias" that was linguistically defensible and generally acceptable. On the whole, though, I don't regret taking the course I did. I have been careful to point out to groups like the Numerical C Extensions Group convened by Rex Jaeschke that I will not cause them "political problems" if someone can come up with a coherent noalias notion that does not cause unbearable problems in the rest of the language. Incidentally, my general dislike of type qualifiers, to which Gwyn referred, was noticeably stimulated by important faults in the definition of "const" in the same Dec. 1987 draft that introduced "noalias." As it turned out, the draft had leftover language in it that was simply unintended, and the committee dealt with these complaints by saying (in effect) "Whoops, we didn't mean to say that." BTW, I think X3J11 did an excellent job, though there are legitimate criticisms. If you want to see others in greater anguish and wrangling, check out Fortran 8X, or the Ada 9X or C++ discussions. Dennis Ritchie dmr@research.att.com att!research!dmr
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/22/89)
In article <14774@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >The whole noalias issue seemed intricately entangled with late 80's >notions of addressing and optimization. In five years it will probably >look quite silly. While it is true that "noalias" would basically have supported optimization technology of the 1980s just as "register" supported compiler optimization technology of the 1970s, I don't think either of them is "silly". This is a legitimate area of concern, particular in a systems programming language. >At worst, if the concept is that vital it will be introduced in some form >as an extension by individual vendors, and if it proves popular and >enduring the next committee can add it from "prior art." Yeah, well in fact several vendors have found it necessary to add their own, nonstandard, idiosyncratic support for this. Since we had already identified the requirement, is it really doing anybody a service to fail to standardize how this is done? I would think quite the contrary. >It is easier for a camel to pass through the eye of a needle than for a >standards committee to make up a useful language extension. I suppose you have some support for this statement?
henry@utzoo.uucp (Henry Spencer) (10/22/89)
In article <11351@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >... a technically defective (but repairable) feature >was REMOVED at the last minute... After being added at the next-to-last minute. As for its repairability, it's not at all clear to me that this was possible. The version in the second-public-review draft was, I'm told, already the result of several major revisions. It still didn't work properly. It sure looked to me -- and I said so in my submission to the committee -- as if the whole issue simply wasn't well enough understood for a solution to be invented with any confidence that it was viable. (When repeated revisions persistently fail to work, the gods are probably trying to tell you something.) That is, it's a research topic, not something to be hastily jammed into an important standard. >It was certainly within X3J11's mandate to invent solutions -- when >necessary to remedy clearly perceived deficiencies... However, it is wise to do so only (a) where matters are well understood, and (b) early in the standards process, so there is time for second thoughts. X3J11 blew it on both of these with noalias. It also seems to me that the areas where X3J11 did invent solutions have attracted a disproportionate share of public criticism, often for good reason. >If you know some better way to draft such a standard, more power to you. >We did the best we could, and I think our consciences are clear. "Success excuses many things." Unless the wording revisions since the third public review have botched something -- I'd be a bit happier if I didn't get the impression that considerable further work was done on what was supposed to be a finished product -- the end product is reasonably good. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tneff@bfmny0.UU.NET (Tom Neff) (10/22/89)
In article <11375@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Yeah, well in fact several vendors have found it necessary to add their >own, nonstandard, idiosyncratic support for [noalias]. Good, now let's let it perk for a few years and see what pragmatic wisdom evolves. Everyone knows the word "noalias" and the general idea; if implementations really are idiosyncratic it may mean that the concept needs reshaping. > Since we had already >identified the requirement, is it really doing anybody a service to fail >to standardize how this is done? I would think quite the contrary. So would IBM, indeed this is the classic IBM approach. Knock domes in Armonk and then descend the mountain bearing tablets graven with new "standards" for the awed peasantry to scratch heads over. Hence PL/I and the two dollar bill. :-) >>It is easier for a camel to pass through the eye of a needle than for a >>standards committee to make up a useful language extension. > >I suppose you have some support for this statement? Absolutely, it goes back to my grade school Religion class at Glenoaks Elementary -- Los Angeles, 1966. (State was going through one of its occasional paroxysms of bonehead conservativism and decided to sneak the kids a dose of Jahweh by the back door.) You had two kinds to pick from - RC and Protestant. (This was before the Bhagwan.) I went to the Protestant; it was held in a nice neighborhood lady's living room. Sunday school is basically what it was. She taught us the famous parable about it being easier for a camel to pass through the eye of a needle than for a rich man to enter the kingdom of Heaven. But this was prosperous middle class Protestant LA here, where being poor was downright un-American, so she had a marvelous prop: mounted on the wall above the mantel was the BIGGEST DAMN NEEDLE EYE you ever saw! About three feet wide, just the eye end of a huge wooden "needle" that supposedly dated from Biblical times (replica more likely, or utterly bogus). The idea was that THIS was the needle Christ had in mind when he opened his mouth, you see. Pretty HARD to pass a camel through there, but you just might do it... So, that's the needle I'm referring to. Not impossible to blue-sky a durable new language feature in committee... just not the way to bet. -- "Of course, this is a, this is a Hunt, you | Tom Neff will -- that will uncover a lot of things. | tneff@bfmny0.UU.NET You open that scab, there's a hell of a lot of things... This involves these Cubans, Hunt, and a lot of hanky-panky that we have nothing to do with ourselves." -- RN 6/23/72
datanguay@watmath.waterloo.edu (David Adrien Tanguay) (10/22/89)
In article <1989Oct22.002400.24104@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >"Success excuses many things." Unless the wording revisions since the >third public review have botched something -- I'd be a bit happier if >I didn't get the impression that considerable further work was done on what >was supposed to be a finished product -- the end product is reasonably good. You can breathe easy on that account. The changes I've noticed between the October and December 88 drafts resulted in a very noticeable improvement in the quality of the technical writing. It's interesting to leaf through a bunch of drafts to see the evolution of some passages, from wording that leaves you thinking "Huh?" to something that actually makes sense. David Tanguay
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/23/89)
In article <30577@watmath.waterloo.edu> datanguay@watmath.waterloo.edu (David Adrien Tanguay) writes: >You can breathe easy on that account. The changes I've noticed between the >October and December 88 drafts resulted in a very noticeable improvement >in the quality of the technical writing. It's interesting to leaf through >a bunch of drafts to see the evolution of some passages, from wording that >leaves you thinking "Huh?" to something that actually makes sense. Our technical editors (mostly Dave Prosser and, before him, Larry Rosler) invested a tremendous amount of effort in trying to get the wording to say what the committee had agreed we should be saying. A large number of improvements resulted directly from the public review process, where even when no technical change was needed to address some issue, we often were able to perceive that there was a need to reword in order to reduce confusion. A number of the very last set of wording changes were devised by a small subgroup that met to review the proposed responses to the third round of formal public review; when we met for this, we discovered that several responses were wrong (in the review subgroup's opinion) or else they amounted to "the editor will fix this", which left us in the position of having to figure out the actual wording changes. The most notable example occurred in section 3.1.2.5, which will immediately be recognized by X3J11 members as the "Types" section. In previous drafts, there had been a technical term "top type" which was introduced solely to help explain type qualification. During every public review we received comments about this, usually starting off "What is this trying to say?" I think we FINALLY managed to explain the topic intelligibly, after numerous previous attempts had failed. I would not have believed how hard it is to write an adequate specification like the C Standard, if I hadn't experienced it first-hand.
henry@utzoo.uucp (Henry Spencer) (10/25/89)
In article <11391@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Our technical editors (mostly Dave Prosser and, before him, Larry Rosler) >invested a tremendous amount of effort in trying to get the wording to >say what the committee had agreed we should be saying... I should elaborate a bit on my uneasiness about late wording changes. The problem is that the public review process necessarily reviewed the document *as written*, not as the committee "agreed it should be saying". Some of the comments along the lines of "well, we finally worded const so it says what we meant" tend to make me feel like saying "if the changes were that significant, should they not have had public review?". >... section 3.1.2.5... the "Types" section. In previous drafts, >there had been a technical term "top type" which was introduced solely to >help explain type qualification. During every public review we received >comments about this, usually starting off "What is this trying to say?" Actually, the ones from me included phrases like "impenetrably obscure", "impossible to figure out what the authors meant", and "the current definition is incomprehensible nonsense". It was, too. And if you tried to figure it out on the law-of-least-astonishment rule, you got the wrong answer! (For one thing, a "top type" was not a type at all.) I was really dismayed that it took *two* public reviews for this to sink in on X3J11. The Oct 1988 wording finally fixed this, and seems to have fixed it right... but this is what I meant, above, about wording changes being significant. I'm a little uneasy about what happened between Oct 88 and Dec 88. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu