🚀 go-pugleaf

In article <307@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes:
>Adding an 'inline' key word allows good code from simpler compilers, however.
>-- 
>Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>

Let me agree at once with Stuart and others that a "good" compiler
should automatically expand procedures inline where appropriate.

However, I think some pragma or hint is needed to tell most
compilers where this is indeed appropriate.  Suppose, for instance,
that a DEFINITION module contains a procedure definition, and the
IMPLEMENTATION module contains the body.  If the procedure is
compiled as true out-of-line code, then you can replace the
implementation (body) without recompiling dependents.  If
however it is made inline, then generally you can't - all the
dependents reference the body and therefore will change.  There
is a tradeoff between execution efficiency and ease of change,
and in general the compiler can't make that tradeoff, because
it doesn't know whether you are in test-&-debug mode or whether
you are in performance assessment mode, or even building the
final load image

At the highest level, therefore, you need a compiler option that
says "yes, go for inline".  At a finer level of control, you
might want to say of any one procedure:

  never inline (rarely called, huge body, or whatever)

  always inline (critical code, body won't change, ...)

  sometimes inline (under option control)

But here I'd state my personal preference for more intelligent
compilers.  In general, the user should give the compiler any
information it CANNOT find out for itself, and no other
information.