🚀 go-pugleaf

How about this as an implimentation technique "in the spirit of C"
-- the programmer gets to say what she want's
-- but only she has to pay for it
-- blatantly cribbed from "normal" C++ implimentations

int func_with_nested_funcs(/*args*/)
{
int  i;
char c;
long l;
/* other variables & code */

/* compiler generates a "struct" definition for all the variables
say __compiler_gen_struct_func_with_nested_funcs__ and passes a pointer
for this to each nested function which use it to access these variables
-- we can flag we don't need this access (e.g. for the compare function
for qsort case by explicitly "void"ing the zeroth (usually invisble) this
pointer position */
     int nested_0(<invisible "this" pointer> /* other args */)
           {
           /* body -- may use i, c & l via "this" */
           }

     char *nested_1(void /*, possibly other args */)
           {
           /* can't use i, c or l since we have inidicated via the
explicit void that we don't want "this" */
           }

/* etc */
}

If we take a pointer for nested_0 we must supply the this pointer 
ourselves (easy if we put all func_with_nested_funcs variables in a
named struct, otherwise an exercise in programmer ingenuity) thus outside
the function nested_0 has prototype "int nested_0(void *, ....)"
-- borrowing again from C++ may be we allow "const" after the function
which would allow:
           int nested_2(/* args */) const { /* implimentation */ }
=> called like int nested_2(const void* /* args */

if we take a pointer to nested_1 we don't have the invisible stuff, 
presumably because we don't need it and the "external" prototype is
the same as the internal one.

This looks like it should work for all C compilers, requires just one
new keyword "this" (possible not even that) -- and two more overloaded
ones (const and void) (more meanings for the same words surely the 
essence of the spirit of C!)

   So where did I go wrong? Surely it can't really be this easy?

     Rod B

Not even speaking for himself....