🚀 go-pugleaf

In article <446ttn$deg@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
>
>>- 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.
>
>Agreed.

I assume this implies that nested functions can not be recursive?

> 
>>- 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.
>
>Ugh. Some C compilers have this extension. These function pointers have a
>special operator (e.g., "!", I think) used to declared the pointer so that the
>compiler can generate different code for them.

Ok, I'll bite: What happens if the nested function references auto variables
in the enclosing function, and then the nested function is called through a
function pointer when the enclosing function is not active and said auto
variable doesn't exist?

>
>>- 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).
>
>UGH.

Yeah. Does my above question apply equally well in this case?





--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com