Re: Is multi-level function return possible?

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Tue, 18 Mar 2014 17:36:46 GMT

          From comp.compilers

Related articles
[20 earlier articles]
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)
Re: design of PL/I, was Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-21)
Re: Is multi-level function return possible? anton@mips.complang.tuwien.ac.at (2014-03-24)
Re: Is multi-level function return possible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-03-24)
Re: Is multi-level function return possible? gneuner2@comcast.net (George Neuner) (2014-03-26)
[7 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Tue, 18 Mar 2014 17:36:46 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 14-03-020 14-03-022 14-03-025 14-03-030 14-03-044 14-03-046 14-03-047
Keywords: Pascal, algol60, history
Posted-Date: 19 Mar 2014 20:12:28 EDT

Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:
>On 16/03/2014 19:45, "Andy Walker" <news@cuboid.co.uk> wrote:
>
>> On 16/03/14 17:19, Anton Ertl wrote:
>>> 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.
>
>It would be wrong to imply that "the Algol-family world" consists of "C and
>its offspring". Algol has many descendants that have have remained more
>loyal to their family traditions, Ada 2012 first among them.


True. But I find it more revealing what features were added back in
after the C branch of the family went through the B bottleneck.
Keeping a feature may just be loyalty, but adding it back after it had
been removed says something about what the language designer thought
about the usefulness of the feature.


Ok, let's look at the arguments I have seen until now:


Name management (information hiding, variable hiding): Languages like
Modula-2 added additional mechanisms for that despite having nested
procedures; C++ did not add nested functions, but did add name spaces.
That argument is not very convincing to me.


"Parameters have a run-time cost": So has access to non-local
variables. Languages that put high priority on run-time cost like C
and C++ did not add that feature (except GNU C), so this argument did
not convince their designers. And it does not convince me.


Hassle when converting Algol to C: I can believe that, but that does
not tell me about the value of the feature in other contexts.


Did I miss any arguments?


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