From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8f8cea8602e61aba X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: The Red Language Date: 1997/09/12 Message-ID: #1/1 X-Deja-AN: 271957306 References: <340ED5D8.2DEF6D3@ux4.sp.cs.cmu.edu> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-09-12T00:00:00+00:00 List-Id: In article , Arthur Evans Jr wrote: >In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > >> Just because a language definition says XXX does not make it so, >> if the statement is vacuous. > >Robert: You are missing the point entirely. If a language definition, >like Ada, is to be useful in the presence of implementors other than the >designer, then of course it's vacuous to imclude specifications that >cannot be tested. > >OTOH, if the only implementor is the designer, and the definition is >provided largely for the language's users, then such specs are of >interest to the users, and therefor useful. That was the situation in >gnal. In other words, the definition of Gnal was one particular compiler. OK, but I can't see how I could be expected to write a compiler for Gnal for a different computer, since I would be required to have the exact timing properties of the "original". Remember this all started by somebody saying Ada was bad, because Gnal *required* inlining, whereas Ada merely *recommends* inlining. I claim that's bogus nonsense. I claim that Gnal *pretends* to require inlining, whereas Ada is more honest, and says that inlining has no semantic effect (but will speed up the code in some (unspecified) cases). >> Remember that a compiler is always allowed to treat a language definition >> "as-if", which means that any generated code that makes a compiler run >> the code the same way as some other way is equivalent. Since inlining >> has, by definition, no semantic effect, it is obvious that semantic >> rules in the language can neither require it nor proscribe it. > >If inlined code is more time-efficient and the app thereby makes its >deadlines but does not otherwise, then there's a semantic effect. The >plane flies one way; it crashes the other. Nonsense. Inlining is *less* efficient in many cases. If you claim that the requirement is that an inlined procedure run faster than a non-inlined one, well that's easy to implement -- the compiler can just put a "delay Ten_Years;" at the start of each non-inlined procedure. Or do you claim that an inlined procedure must run faster than the most-efficient, cleverest non-inlined version? Well, then, show me the cleverest compiler writer as part of your language definition. >> As for "we believed him, why not?", the why not is because the claim was >> on its face unsupportable! > >There are places in this world where folks say things and other folks >believe them. The GNAT documentation explains the circumstances in >which 'pragma inline' has an effect; I believe what is written. In >fact, I could test the claim by examining compiled code; why bother? Sure, you trust the GNAT docs. So do I. But that doesn't mean Gnal is somehow better than Ada in *requiring* inlining as opposed to merely *recommending* inlining. I claim that, in a language standard, requiring and recommending are equivalent in this case, and it's obfuscatory to pretend that "require" means anything. It certainly doesn't mean the code will run faster. Proof: Take your favorite large Ada program, and enable inlining on every subprogram. If the compiler is doing its job, then that program will most certainly run slower. (Note I said "large".) - Bob