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,799e6e37c90ca633
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Future Ada language revisions?
Date: 1998/10/23
Message-ID: <EACHUS.98Oct23140240@spectre.mitre.org>#1/1
X-Deja-AN: 404365250
References: <70lquh$mrp@netline.jpl.nasa.gov> <wccsoghbg1d.fsf@world.std.com>
 <Pine.BSF.4.05.9810212137240.17208-100000@shell5.ba.best.com>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1998-10-23T00:00:00+00:00
List-Id: <comp.lang.ada>

In Bob Duff wrote:

   > The Ada 9X team proposed exactly that.  As an alternative, we also
   > proposed a set of rules that would allow copying, but not to a
   > more-global place.  Both of these proposals were rejected, primarily on
   > the grounds that they are hard to implement if the compiler uses a
   > "display" to implement a procedure's environment, rather than a "static
   > link".

   > I think it was a mistake.  I liked the "limited" idea best.  It matches
   > Pascal's semantics for passing procedures as parameters.  This is the
   > only case I can think of where Ada is less powerful than Pascal.

   I think it should have been added too, but I didn't fight it at the
time because, as Jean-Pierre Rosen demonstrated, the generic
"workaround" is exactly equivalent.  Incidently, once I understood
this, I talked to someone from R&R Software who confirmed that their
compiler (which used displays) had the necessary code "in there"
becuase there was one ACVC test that broke if they didn't save and
restore displays.

   However, I think it is now time to consider providing a better
syntax, in particular the limited keyword.  Using generic
instantiation to provide downward closures may just require a few
extra lines of code, but the mental effort required to use it is much
too high.  In fact, it has always amazed me how difficult it is for
most Ada programmers to understand WHY generic instantiation occurs at
run-time.  Generic instantiatiation is really a process for saving a
snapshot of a (dynamic) context.  In a language like Algol 68 it would
be obvious which generic formal parameters were snapshotting the
current value, and which parts were really imaging the reference to
the parameter.  In Ada you can go either way for just about anything,
but the syntax doesn't make it obvious that this is occuring:

   "In an instance, a formal_object_declaration of mode in declares a
new stand-alone constant object whose initialization expression is the
actual, whereas a formal_object_declaration of mode in out declares a
view whose properties are identical to those of the actual." RM 12.3(10)

   So in:

with Text_IO; use Text_IO;
procedure Gen_Test is
  type String_Pointer is access String;
  generic
    Foo: in String;
    Bar: in out String;
    Foobar: in out String_Pointer;
  function Test return String;
  function Test return String is
  begin return Foo & Bar & Foobar.all; end Test;
  X: String_Pointer := new String'("ABCD");
  function Test1 is new Test(X.all,X.all,X);
begin 
  X.all := "EFGH";
  X := new String'("IJKL");
  Put_Line(Test1);
end Gen_Test;

   Foo is a snapshot of the current value of X.  Bar is a reference to whatever
object X currently points to, and Foobar is a view of X.  So the
program prints:

spectre% gen_test
ABCDEFGHIJKL

   (You don't access types to get this effect, I just used them to
make it clear that the in out parameter is keeping a view of the old
X.all in Foo not a copy of the value of X, and this is different from
the view of X that is passed to Foobar.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...