🚀 go-pugleaf

In article <448uaq$28g@rdsunx.crd.ge.com> volpe@bart.crd.ge.com
(Christopher R. Volpe) writes:

|> 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?

The same thing that happens if you stash a pointer to an auto variable
somewhere, and use it once the function has returned.

|> >
|> >>- 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?

Yes, and with the same answer.

I think that to be really useful, nested functions would practically
have to be according to the last suggestion.  But unless your system
is capable of generating trampolines, this will impose significant
overhead for *all* function pointers.

Which is why I don't expect to see nested functions adapted.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung