Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: antispam@math.uni.wroc.pl Newsgroups: comp.compilers Subject: Re: Add nested-function support in a language the based on a stack-machine Date: Sun, 29 Apr 2018 16:29:00 +0000 (UTC) Organization: Politechnika Wroclawska Lines: 79 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <18-04-079@comp.compilers> References: <18-02-009@comp.compilers> <18-02-012@comp.compilers> <18-02-016@comp.compilers> <18-02-018@comp.compilers> <18-02-023@comp.compilers> <18-02-029@comp.compilers> <18-02-032@comp.compilers> <18-02-034@comp.compilers> <18-03-002@comp.compilers> <18-03-012@comp.compilers> <18-03-020@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="16184"; mail-complaints-to="abuse@iecc.com" Keywords: code, design Posted-Date: 29 Apr 2018 13:44:51 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com X-Received-Bytes: 3916 X-Received-Body-CRC: 3286164173 Xref: csiph.com comp.compilers:2088 George Neuner wrote: > On Fri, 02 Mar 2018 09:30:42 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: > > >George Neuner writes: > >>On Sat, 17 Feb 2018 16:39:04 GMT, anton@mips.complang.tuwien.ac.at > >>(Anton Ertl) wrote: > >> > >>>Kaz Kylheku <217-679-0842@kylheku.com> writes: > >>>>On 2018-02-15, George Neuner wrote: > >>>>> No worries. IME, displays don't get much respect from modern > >>>>> textbooks - they are mentioned mostly in passing. > >>>> > >>>>This is probably because of > >>> > >>>This is because displays were found to be more costly for Algol-like > >>>languages > >> > >>More costly than what? > > > >Static link chains. > > > >>> IIRC the additional cost is in updating the display on calls > >>>and returns. > >> > >>Which is no different from the overhead to maintain static links > > > >Wrong. Consider the following nesting of functions: > > > >A > > B > > C > >D > > > >With a display, in C you have built up a display pointing to the > >frames of C, B, and A. When performing a call from C to D, you throw > >that away and replace it with a display pointing to just the frame of > >D. When returning from D, you have to restore the old display. > > No. D and A are at the same lexical level. On entry, D will replace > A's entry in the display, and will restore A's entry on exit. > > The scope rules say D can't see or call B or C. If it calls A, then A > replaces it at the same lexical level. When A returns, D's link is > restored. You assume no procedure parameters (boring case). With procedure parameters C can pass itself (or B or other procedure at the same lexical level) to D and D can call it. So dynamic chain can be: A B C D C and innermost C needs to see A variables in its display. IIUC resolving this required copies that make display management O(n) (n being depth of static chain). > No problem. And no need to preserve the whole display. > > >If you don't maintain a static link chain, you have to save the > >complete display of C on the call and restore it on return. > > No you don't. > > > >Note that D may itself call functions that need more display, so you don't get > >away with just saving and restoring the first slot of the display. > >IIRC this was the variant looked at in the paper that concluded that > >displays are more costly. > > That is simply wrong unless you change the whole semantics. > > As long as call sites are restricted to being within the definition > scope of the called function [as is true in Pascal], Pascal without procedural parameters. -- Waldek Hebisch