🚀 go-pugleaf

In article <11458@cca.UUCP> bills@cca.UUCP (Bill Stackhouse) writes:
>
>Something I would like to see in all procedure based languages
>is some syntax in the procedure def. that indicates that the
>procedure is to be included inline at all places it is called.
>That would allow the abstraction to still occur but would do
>away with the overhead of calling and returning just for a few
>lines of code.

Good idea.
			  Marty Smith

In article <11458@cca.UUCP> bills@cca.UUCP (Bill Stackhouse) writes:
>
>Something I would like to see in all procedure based languages
>is some syntax in the procedure def. that indicates that the
>procedure is to be included inline at all places it is called.

   This is implemented in C++, and in many Ada compilers (it's an
optional pragma).
   
-- 
    Dan Frank
    uucp: ... uwvax!prairie!dan
    arpa: dan%caseus@spool.wisc.edu

In article <4814@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes:
>In article <11458@cca.UUCP> bills@cca.UUCP (Bill Stackhouse) writes:
>>
>>Something I would like to see in all procedure based languages
>>is some syntax in the procedure def. that indicates that the
>>procedure is to be included inline at all places it is called.
>>That would allow the abstraction to still occur but would do
>>away with the overhead of calling and returning just for a few
>>lines of code.
>
>Good idea.
>			  Marty Smith

 *Bad* idea!! It is up to the *compiler* to judge whether or not to do this...
  
				  Bill Wolfe  (ahe!k.cc.purdue.edu)
				  

In article <4814@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes:
>In article <11458@cca.UUCP> bills@cca.UUCP (Bill Stackhouse) writes:
>>
>>Something I would like to see in all procedure based languages
>>is some syntax in the procedure def. that indicates that the
>>procedure is to be included inline at all places it is called.

In article <11458@cca.UUCP>, bills@cca.UUCP (Bill Stackhouse) writes:

> x = packed record of
>   b1, b2, b3, b4 : boolean;
>   i : 0..63;
>   b5, b6, b7, b8, b9, b10 : boolean;
> end;

This has my vote.  Even bit arrays fit this idea (packed array of . . .)

> Something I would like to see in all procedure based languages
> is some syntax in the procedure def. that indicates that the
> procedure is to be included inline at all places it is called.

Many global optimizers do this automatically.  Procedures less than
a certain size or called a small number of times are automatically
converted to inline.  This optimization can even be performed on the
binary!  (I.e. language independent)

Adding an 'inline' key word allows good code from simpler compilers, however.
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>

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.

The decision to include procedures inline may often be better done by compilers
but compilers often do not have all of the information necessary to make good
decisions.  The idea that compilers should play god and that they are always
better decision makers is just not true.  The ability of the programmer to
specify inline inclusion is usefull and it would be just as useful for the
programmer to be able to inhibit inline inclusion for compilers which do
such inclusions themselves.

I am a compiler developer with 10 years experience and I know that programmers
may not always make the best decisions but it is not my job to control them.
It is my job to provide the best product I can (that includes documentation) 
and to give the programmer the best set of options I that I am able to.

[My opinions are my own and may not necessarily be those of my employer.]

In article <1654@k.cc.purdue.edu> ahe@k.cc.purdue.edu.UUCP (Bill Wolfe) writes:
>In article <4814@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes:
>>In article <11458@cca.UUCP> bills@cca.UUCP (Bill Stackhouse) writes:
>>>
>>>Something I would like to see in all procedure based languages
>>>is some syntax in the procedure def. that indicates that the
>>>procedure is to be included inline at all places it is called.
>>>That would allow the abstraction to still occur but would do
>>>away with the overhead of calling and returning just for a few
>>>lines of code.
>>
>>Good idea.
>>			  Marty Smith
>
> *Bad* idea!! It is up to the *compiler* to judge whether or not to do this...
>  
How does the compiler know what I want unless there is a way I can tell the
compiler what I want?  Some people take this artificial intelligence thing
a little too far?
					  Marty Smith

In article <4814@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes:
>In article <11458@cca.UUCP> bills@cca.UUCP (Bill Stackhouse) writes:
>>
>>Something I would like to see in all procedure based languages
>>is some syntax in the procedure def. that indicates that the
			^^^^^^^^^
>>procedure is to be included inline at all places it is called.

In article <475@aw.sei.cmu.edu.sei.cmu.edu>, firth@sei.cmu.edu.UUCP writes:
> 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. [...]

   The original article referenced *procedures* and not modules.
   Furthermore, in the case of a module, the compiler has NO CHOICE but to
   generate out-of-line code; the separateness must be maintained.
   
In article <475@aw.sei.cmu.edu.sei.cmu.edu>, firth@sei.cmu.edu.UUCP writes:
> 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.

   The compiler already has all the information it needs.  When one
   specifies "module", the compiler can, should, and will take this 
   as a clear indication that the code is *not* to be expanded in-line.
   
						  Bill Wolfe
				       

In article <1656@k.cc.purdue.edu> ahe@k.cc.purdue.edu (Bill Wolfe) writes:
>In article <4814@ism780c.UUCP> marty@ism780c.UUCP (Marty Smith) writes:
>>In article <11458@cca.UUCP> bills@cca.UUCP (Bill Stackhouse) writes:
>>>
>>>Something I would like to see in all procedure based languages
>>>is some syntax in the procedure def. that indicates that the
>			^^^^^^^^^
>>>procedure is to be included inline at all places it is called.
>
>In article <475@aw.sei.cmu.edu.sei.cmu.edu>, firth@sei.cmu.edu.UUCP writes:
>> 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. [...]
>
>   The original article referenced *procedures* and not modules.
>   Furthermore, in the case of a module, the compiler has NO CHOICE but to
>   generate out-of-line code; the separateness must be maintained.
>   

And I was talking about procedures defined in modules.  In M2, ALL
procedures are defined in modules, so we are talking about the same thing.

The Modula-2 Report [third edition, Ch 14] requires only that modules be
separately compiled, it does not require that an implementation module be
REcompilable without visible effect.  This is mentioned in the user
manual merely as one possible feature of a "sophisticated" Modula compiler.

>In article <475@aw.sei.cmu.edu.sei.cmu.edu>, firth@sei.cmu.edu.UUCP writes:
>> 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.
>
>   The compiler already has all the information it needs.  When one
>   specifies "module", the compiler can, should, and will take this 
>   as a clear indication that the code is *not* to be expanded in-line.
>   
>						  Bill Wolfe
>				       

Such a compiler would be wrong.  It really does help to read the language
definition, you know.