Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| From: | bartc <bc@freeuk.com> |
| Newsgroups: | comp.compilers |
| Date: | Tue, 6 Mar 2018 19:02:27 +0000 |
| Organization: | Compilers Central |
| References: | 18-02-009 18-02-012 18-02-016 18-02-018 18-02-023 18-02-029 18-02-032 18-02-034 18-03-002 18-03-012 18-03-020 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="79889"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | code, comment |
| Posted-Date: | 07 Mar 2018 12:44:33 EST |
| Content-Language: | en-GB |
On 05/03/2018 19:39, George Neuner wrote:
> On Fri, 02 Mar 2018 09:30:42 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>> 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.
What scope rules? As I don't think this is for a specific language.
Even in C, some versions of which have nested functions, it is possible
to set up a function pointer to C(), which can later be called from D()
without first calling A().
And in my own language, it is possible for code in D() to directly call
A.B.C() without entering A.
Although in this one, C() can't access any stack-allocated data of B or
A; partly for this reason (data may not be undefined if called from
outside), and also because it would be fiddly to do anyway, even if
called from B() and A(), as the thread demonstrates.
(C() can access static data of A() and B(), also types, named constants,
enums, and other local functions, so it can still be worthwhile having
local functions with such a restriction.)
--
bartc
[The discussion so far has mostly been about Algol/Pascal style
languages where you can't peek into blocks and contexts go away when a
routine returns so there are no closures. I agree that if you relax
those rules, life gets more complicated.
Hypothetical question: Algol60 call by name was a mistake. They
intended an elegant definition of call by reference and didn't realize
until Jensen's device what they'd done. If they'd done what they
intended and we didn't have to invent thunks, how would programming
languages be different? -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.