🚀 go-pugleaf

In article <dqua.811915828@dqua> dqua@earthlink.net (Derick J.R.  
Qua-Gonzalez) writes:
> Lawrence Kirby <fred@genesis.demon.co.uk> writes:
> 
> >In article <1995Sep22.171416.1574@ittpub> wil@ittpub.nl "Wil Evers"  
writes:
> 
> >>All languages that allow a nested procedure to access the local  
variables  
> >>of the enclosing procedure(s) and use lexical scoping have this  
problem.  
> 
> >Function nesting can be useful for scoping even when local variables of
> >enclosing functions are no accessible. If I remember correctly this is
> >what BCPL supported. It is a shame that C threw this facility away.
> 
> Hey Lawrence...
> 
> I completely agree with you that C would have been nice with nested
> functions. On a stack-based machine, implementation of the scoping
> can be easily done, looking up the call of stack frames.
> 
> In C++, the namespace facility comes close.

Please note that I did not intend to take sides in the debate over nested  
functions in C. I was only trying to point out why a nested function that 
(1) is called from different lexical nesting levels and (2) needs access  
to the variables in one of its lexcially enclosing scopes needs a  
different execution model.

Personally, I don't think this difference in execution model is enough  
reason to forget about nested functions. There are several solutions to  
this problem:

- Disallow nested functions to directly access the locals from one of its  
enclosing scopes, as Lawrence Kirby suggests. This is my favorite because  
it's easy to understand and enforces explicit passing of access to local  
variables.
- Disallow calls to the same nested function from different lexical  
nesting levels. This is probably the least attractive option because users  
will have a hard time grasping this and compilers have to check for it. 
- Use a different execution model for nested functions only. This is what  
most Pascal compilers do. In C, there would be major problems in  
expressing pointers to such functions. We would need a syntax to express a  
'pointer to function nested in <this other function>' or live with a big  
loophole in the type system.
- Use the nested function execution model for all functions, nested or  
not. Here, we would have problems in linking with existing pre-compiled  
libraries, but we could probably do with only one pointer to function type  
(which would still not be completely type-safe, because the context in  
which a function is called can't be easily checked now).  

Whether or not it's all worth it is another matter. In the years I did  
Pascal programming, I never used nested functions, mainly because I don't  
like having implicit access to the locals of some other function at all. I  
never came accross a case that could not be solved without nested  
functions.  

- Wil