From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,99ab4bb580fc34cd
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Q: access to subprogram
Date: 1996/07/03
Message-ID: <Dtyt4K.Jvx@world.std.com>#1/1
X-Deja-AN: 163464666
references: <4rb9dp$qe6@news1.delphi.com> <Dtxu2p.97F@world.std.com>
 <JSA.96Jul2221357@organon.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-07-03T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <JSA.96Jul2221357@organon.com>,
Jon S Anthony <jsa@organon.com> wrote:
>Is there an "elevator version" of why people didn't want this in?  Tucker,
>if you are reading this, what swayed you to not let this in????  It's
>not one of those things that bothers me all that much (well, it hasn't)
>but it is indeed curious...

There are two major ways of implementing up-level variable references in
a language with nested procedures: Static links, and displays.  With
displays, it is somewhat difficult to implement passing nested
procedures as parameters, because you have to pass the display, which is
not of compile-time-known size.  Passing a static link is easy -- it's
just a single address.  Some implementations of Ada 83 used displays.
The primary reason for not putting the feature in was to ease the pain
for such implementations.  This was done at a time when the general
feeling was that Ada 9X had more than enough new features, and we
shouldn't be adding things, but removing them.

- Bob