Re: The Red Language

[bobduff@world.std.com (Robert A Duff)]

In article <evans-1109972149130001@ppp33.s8.pgh.net>,
Arthur Evans Jr <evans@evans.pgh.pa.us> wrote:
>In article <dewar.873953773@merv>, 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