Re: The Red Language

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Art says

<<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.
>>

No, Art, you are still confusing a language definition with implementation
notes. Who implements the language specification is quite irrelevant!

<<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.>>

A very common confusion, actually two confusions mixed up.

  1. A language definition usually has nothing to say about timing
     performance, so a compiler is free to implement any statement
     efficiently or inefficiently. Since there is no constraint on
     efficiency, a change in efficiency is NOT a semantic effect,
     even though it may affect the timing of the program. Basically
     if you take timing into consideration, then all the language
     semantics are non-deterministic, and a change in performance
     is simply a manifestation of this non-determinism.

  2. You are assuming that inlining necessarily makes the program run
     faster. This is not at all the case:

        2a. Any movement of code like this may alter instruction cache
            effects, and arbitrarily slow down or speed up execution.

        2b. On some machines it is simply less efficient to inline the
            code. For example, on the IBM 360, if you inline, then you
            increase base register pressure, whereas out of line, the
            call establishes a convenient local base register.

     So it cannot be the case that ignoring inlining is an effect because
     it would slow things down and make the app miss its deadline, it is
     equally likely that *doing* the inlining would slow things down and
     make the deadline be missed.

It is point 2 incidentally which leads us to be a bit vague in Ada about
what pragma Inline means, even informally. Generally a programmer who
specifies pragma Inline is asking for the compiler to generate code that
is as fast as possible, even if it requires more space. In a situation
where inlining would slow things down, it seems quite reasonable, even
desirable for the compiler to ignore the request.

> 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
  check 3612-003>>

But the issue is whether GNAL achieved the effect of requiring inlining
*at the language definition level*. That's the issue here. Sure you
can believe an implementor who says something about his implementation,
and it was quite reasononable for you to believe that. However, you have
given no basis at all for believing that he achieved the goal of requiring
inlining at the language definition level.

Remember it was you who started this thread with the claim that GNAL, unlike
Ada, required inlining at the language definition level. You have not at all
substantiated that claim (nor do I think it is possible for you to do so!)