🚀 go-pugleaf

In article <43j992$623@gabi.gabi-soft.fr> kanze@gabi-soft.fr (J. Kanze)  
writes:
> Paul Long (plong@perf.com) wrote:

[snip]

> |> Although there are C-like languages that support nested functions,
> |> e.g., Gnu C, I've recently learned that the execution model must
> |> change to support them. Not a pretty sight.
> 
> I'm curious.  In what way must the execution model be changed?

[snip]

All languages that allow a nested procedure to access the local variables  
of the enclosing procedure(s) and use lexical scoping have this problem.  
Consider this 'nesting C' fragment:

void x(void)
{
	int v;

	void y(void)
	{
		/* some accessed locals */
		v = 1;
	}

	void z(void)
	{
		/* some accessed locals */
		y();
	}

	y();
	z();
}

Here, y() is called from x() as well as from z(). If y() is called from  
x(), x's local variable v is in the stack frame next to y's; if it is  
called from z(), v is in the stack frame two frames away from y's. In  
other words, every time y() is called, some pointer must passed to it so  
it can find the stack frame of the lexically enclosing procedure. Many  
text books refer to this pointer as the static link (the saved frame  
pointer of the calling procedure is called the dynamic link).
Since C today has no nested functions, all directly accessible variables  
are either in the processor registers, the local stack frame or the  
program's global data area, so there is no need for a static link.

- Wil