Re: Is multi-level function return possible?

Bakul Shah <usenet@bitblocks.com>
Sat, 15 Mar 2014 10:28:08 -0700

          From comp.compilers

Related articles
[14 earlier articles]
Re: Is multi-level function return possible? kaz@kylheku.com (Kaz Kylheku) (2014-03-14)
Re: Is multi-level function return possible? kaz@kylheku.com (Kaz Kylheku) (2014-03-14)
Re: Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-14)
Re: Is multi-level function return possible? marcov@toad.stack.nl (Marco van de Voort) (2014-03-14)
Re: Is multi-level function return possible? ian@airs.com (Ian Lance Taylor) (2014-03-14)
Re: Is multi-level function return possible? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2014-03-15)
Re: Is multi-level function return possible? usenet@bitblocks.com (Bakul Shah) (2014-03-15)
Re: Is multi-level function return possible? noitalmost@cox.net (noitalmost) (2014-03-15)
Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (2014-03-16)
Re: Is multi-level function return possible? marcov@toad.stack.nl (Marco van de Voort) (2014-03-16)
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-16)
Re: Is multi-level function return possible? yaldnif.w@blueyonder.co.uk (Bill Findlay) (2014-03-17)
Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (2014-03-18)
[10 later articles]
| List of all articles for this month |

From: Bakul Shah <usenet@bitblocks.com>
Newsgroups: comp.compilers
Date: Sat, 15 Mar 2014 10:28:08 -0700
Organization: Sonic.Net
References: 14-03-020 14-03-022 14-03-025
Keywords: Pascal, code
Posted-Date: 16 Mar 2014 00:08:30 EDT

On 3/11/14, 3:15 PM, Kaz Kylheku wrote:
  >
  > Recursion means there is possibly more than one activation of the environment
  > which contains the target label of the goto. Which activation is chosen as the
  > jump target? Does the goto return to the same recursion level in which
  > the closure was created or does it just find the innermost activation of
  > that label?
  >
  > If the closure jsut goes to the innermost block which has the label,
  > then the target resolution is in fact dynamically scoped, even though
  > the label is lexical. (Because the target block is not lexically captured
  > along with the closure, but chosen just from whatever is visible at the
  > time the goto takes place.)


No, the label/goto scoping is strictly lexical. What happens is you
pop all the frames until you reach the frame of the correct lexically
enclosing routine with the defined label and then set PC to the
address of the instruction the label points to.


Here's a convoluted example using C syntax (but Pascal's goto and
nested function semantics):


typedef int(*int_f)(int);


int fun(int_f g) {
                    return g(1) + g(0);
}


int top(int v, int_f f) {
                    int sub(int x) {
                                    if (x == 0)
                                                    goto lab1;
                                    return x+1;
                    }
                    int HOfun(int_f argfun1) {
                                    top(v-1, argfun1);
                    }
                    if (v > 1)
                                    return HOfun(sub);
                    return fun(f);
lab1:
                    return -1;
}


When top is called with v=2 and f=some random function, it
will call HOfun with argfun1=sub. HOfun calls top again and
passing its argfun1. Now top calls fun with the passed in
function, which sub (but from the previous call to top). When
fun calls g (which is really sub) with x=0, the stack has
these activation frames:


top // original call
HOfun
top // call from HOfun
fun
sub


Since sub's static link points to the frame of the original call to
top, four frames will be popped & PC set to the instruction named by
lab1. BTW, label declarations have to precede function/procedure
declarations so that a one pass compiler can identify the correct
enclosing scope!


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.