Re: Is multi-level function return possible?

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Sun, 16 Mar 2014 17:19:06 GMT

          From comp.compilers

Related articles
[16 earlier articles]
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)
Re: Is multi-level function return possible? news@cuboid.co.uk (Andy Walker) (2014-03-21)
Re: Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-21)
[11 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Sun, 16 Mar 2014 17:19:06 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 14-03-020 14-03-022 14-03-025 14-03-030
Keywords: code, design, Pascal
Posted-Date: 16 Mar 2014 14:04:48 EDT



George Neuner <gneuner2@comcast.net> writes:
>YMMV, but ISTM that recursion is not really relevant to the issue:
>lexical scoping by itself introduces the potential for name shadowing
>and the rule always has been to reference the instance which is
>defined "closest" to the point of use. The addition of recursion
>simply makes locating that closest instance - at least in part - a
>runtime operation rather than a compile time operation.


Take a look at the example from Bakul Shah in
http://compilers.iecc.com/comparch/article/14-03-042. There the "goto
lab1" skips one invocation of top to jump into a top frame that is
further out. There is no more run-time operation necessary than
without recursion: the goto just follows the static link chain for as
many levels as are lexically between the goto and the target label (in
this case one), that's all.


>Standard Pascal did have not have closures: you could pass a function
>by name as an argument to another, but its definition had to be
>visible both at the point of passing the name and at the point of
>invocation [through the aliasing argument].


Not sure what you mean with "the aliasing argument", but the original
name need not be visible at the point of invocation. Pascal's
function/procedure arguments have many properties of full closures, in
particular access to variables of enclosing scopes, but unlike
first-class closures, you could not store them into variables or pass
them out from functions.


Language design note: Given that nested functions have fallen out of
favour in the Algol-family world (in C and its offspring), I wonder if
they only really gain usefulness when combined with first-class
closures.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/


Post a followup to this message

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