🚀 go-pugleaf

David Chase <chased@rbbb.Eng.Sun.COM> writes:
>This is not correct.  Nested functions are not expensive to implement.

OK, how do you do it so that:
     o	It's efficient enough on a wide class of architectures that I don't
	care about the overhead involved in using it.
     o	There is no penalty for _not_ using it.
     o	It invokes the subroutine in the context where its address was
	evaluated, even under recursion.
     o	It's thread-safe; that is, the compiler doesn't create any global
	variables or the like behind my back.
     o	The address of the function is compatible with a ``standard''
	function variable.

Note that if you can do this, it would be possible to bind a non-static class
member function and a class object together, assign that to a ``standard''
function variable, and arrange that when the function variable was invoked,
the class member function would be invoked on the object.  The mechanisms
involved are equivalent.

>I speak as someone who has done it.

Well, I haven't done it myself, but in a previous incarnation I got to grovel
through a lot of PL/I code that used the equivalent of function pointers.  The
code generated on an IBM/360 was astoundingly inefficient.

Of course, one can't make a general argument from one data point, but if
function pointers are that expensive on a not-unreasonable architecture,
you'll have to convince me that they can be considered ``inexpensive''
in the general case.  I'm willing to be proven wrong, but it will take
more than just an assertion that it can be done.

>Compared to the costs of programming, and the potential wins ... nested
>functions are a clear win.

Don't get me wrong---I would like to have nested functions.  But the same
logic that prevented the adoption of an exponention operator is in effect
here: it can be ``unexpectedly'' costly.

>>The ``Spirit of C'' ... ; C++ inherits much of this spirit.
>Is this good or bad?

It's neither good nor bad; it just is.  But it must be understood when
considering how the language is put together.
-- 
-- Greg Noel, Unix Guru         greg@qualcomm.com  or  greg@noel.cts.com