🚀 go-pugleaf

greg@qualcom.qualcomm.com (Greg Noel) writes:

>If you look at what a compiler must do to implement this, it has to create
>a ``structure'' (the stack frame) that contains all the local variables,
>the parameters, and so forth, and arrange for the nested function to be
>able to find that structure with a sort of implicit ``this'' pointer.  In
>a heavily optimizing compiler that keeps many values in registers, it can
>be costly to have to re-sync memory every time a nested function _might_
>be invoked.

Since you always have the full text of the nested function available, and
you know exactly which variables it references, and you know exactly which
function calls might call it, this cost is borne only when it is actually
needed.

>On top of that, if you wish a function to retain its scope during a potentially
>recursive invocation, it means that the implicit ``this'' pointer must be
>kept as a part of the pointer, which would increase the size of _every_
>pointer, whether the feature is used or not.  That was a real killer for
>PL/I function pointers and very much against the C philosophy.

Only function pointers, of course.  For those who hate this cost, the
GCC approach of generating a helper function on the stack works well.  Then
you pay a slightly higher cost for the invocation, but only when it is
actually necessary.

>(BTW, I'd like to have nested functions, but I would not make pointers to
>them be compatible with a ``normal'' function pointer.  Nested functions
>are handy to improve the clarity of code, but I'd want the compiler to
>have total knowledge over when they were invoked and allow it to optimize
>them as it saw fit, so that it could inline them or use special lightweight
>calling sequences if it wished.

It's not a compiler problem.  The compiler has all of the knowledge
it needs.  It's pretty hard to inline a function through a pointer, though.

The arguments against nested functions are primarily based on compatibility
with C and on not making unnecessary changes to the language.  Implementation
costs in the generated code are quite small, and are paid only when needed.
Pointers to nested functions also add yet another area of undefined
behavour, just like pointers to local variables.

I find that my style of programming in C++ pretty much (but not entirely)
eliminates the desire for nested functions as lexical closures, so I won't
argue for them very strongly.
-- 
Michael S. Ball (mike@taumet.com)
TauMetric Corporation