🚀 go-pugleaf

In article <1995Sep25.114935.1575@ittpub> wil@ittpub.nl (Wil Evers)
writes:

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

The easiest solution to this problem would be to simply ban taking the
address of nested function.  For the rest: I disagree with the term
``different execution models''.  The compiler must, however generate
different code; I presume that this is what you are talking about.

The problem with this approach is that it eliminates one of the most
useful forms of nested functions.

I believe that trampolines have also been used to overcome this
problem.  When the address of a nested function is taken, a small
initialization program is generated on the fly, to set up the extra
pointers, and then jump to the actual function.  The pointer to
function points to this program.

I suspect that there are memory management issues associated with this
approach.

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

The problem with using only one pointer type (if the trampoline
approach isn't used) is that everyone pays for nested functions,
including people who don't use them.  This seems very much against the
C tradition.

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

I've had a couple of cases where creating a function to pass to qsort
meant having to store a couple of parameters in (file scope) static
variables, in order to access them in the function.  And maybe one or
two other times when they would have been extremely useful (in about
10 years programming in C).

In C++, I can simulate the effect fairly well (adequately?) by having
functions take a pointer to a class with overloader operator(),
instead of a pointer to a function.  In many ways, it is a remarkably
flexible idiom, but I'm not sure the effect on program readability is
particularly positive.  (On the other hand, people reading C++ code
should be used to expect the unexpected, so I guess it's alright.)
-- 
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