🚀 go-pugleaf

In article <43v2a8$b2g@hermes.acs.unt.edu> johnw@jove.acs.unt.edu
(John Robert Williams) writes:

|> <42s5su$4h8@inforamp.net> <42u8sr$hv8@bud.shadow.net> <437fk4$5no@eco.twg.com> <439nh8$p7o@news0.rain.rg.net> <43j992$623@gabi.gabi-soft.fr>
|> Distribution: 

|> J. Kanze (kanze@gabi-soft.fr) wrote:
|> > Paul Long (plong@perf.com) wrote:
|> > |> 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?

|> I think he may be referring to what must be done to allow recursive 
|> nested functions; since local functions have access to their parent's 
|> local variables (in Pascal, at least), you would have to always pass a 
|> pointer to the parent function's variables as a hidden parameter, much 
|> like C++ member functions (actually that gives me a greate idea for 
|> implementing nested functions in C++, but that's another thread).

Since I started this thread...

I guess it depends on what you consider the execution model.  I always
thought of things like sequence points made up the execution model.
As far as I know, the C execution model, as defined in 9899, doesn't
even have a stack and stack frames, so any changes regarding how such
are managed could not affect the execution model as presented in the
standard.  (They would certainly have an effect on the generated
code.)

BTW: I though the usual solution for the problem of accessing the
parent function's variables was trampolines, and not an extra
parameter?  This *is* important in a C implementation in order to
implement function pointers that have no extra overhead in the case
where nested functions are not used.

And of course, a good compiler may often be able to determine that the
trampoline is not needed anyway.

Also: the C++ committee considered and rejected nested functions.  I
believe that at least part of the reason for the rejection was that
there exist (or might exist) architectures on which trampolines cannot
be implemented, and in this case, function pointers become more
complex, which violates the ``you only pay for what you use''
principle.
-- 
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