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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!pyrnj!mirror!gabriel!ada-uts!richw
From: richw@ada-uts
Newsgroups: net.lang.ada
Subject: Re: Orphaned Response
Message-ID: <4700074@ada-uts>
Date: Thu, 7-Aug-86 00:58:00 EDT
Article-I.D.: ada-uts.4700074
Posted: Thu Aug  7 00:58:00 1986
Date-Received: Sat, 9-Aug-86 08:57:36 EDT
References: <679@EDU>
Nf-ID: #R:EDU:-67900:ada-uts:4700074:000:2773
Nf-From: ada-uts!richw    Aug  7 00:58:00 1986
List-Id: <comp.lang.ada>


>>  Wrong conclusion.  If a language allows the program you describe
>>  then any implementation that behaves the way you're worried about
>>  is wrong.

I'm not sure what you're saying; it seems clear to me that either (a)
Ada-with-procedure-pointers allows my program, i.e. the program
successfully compiles, or (b) the program is rejected by the compiler.
(a) leads lets users write unsafe programs; (b) complicates the
semantics of Ada and places serious restrictions on what you can do
with procedure pointers.  It's as simple as that.

To be honest, my intention was not to prove that the addition of
procedure pointers to Ada would necessarily make Ada an unsafe
langauge -- instead, I just wanted to show that there are indeed
non-trivial problems in adding procedure pointers to Ada.  These
problems have not been sufficiently considered in the notes I've read
to date.

For instance, as you pointed out, activation records could be
allocated on the heap.  While this is very well possible, the
question then arises as to who reclaims that storage.  Whereas
the user normally has control over garbage collection (if his
or her compiler even provides garbage collection; most don't)
via "pragma CONTROLLED" and UNCHECKED_DEALLOCATION, this would
not be the case for activation records placed in the heap --
the user would have no way of referring to "activation-record"
objects.  It seems that, without further additions to the language,
compilers would be forced to automatically reclaim heap-allocated
activation records -- while this is again possible, this would
complicate compilers quite a bit.  And if compilers did indeed
provide automatic garbage collection of these activation records,
this would have serious consequences for real-time applications
which could not afford unexpected, momentary lapses due to
garbage collection.  Remember, Ada was designed with real-time
applications in mind -- imagine your fighter-plane refusing to
take evasive actions because it needed to garbage collect.

As you can see, the addition of procedure pointers to Ada opens up
quite a can of worms.

To consider another alternative, yes, you could restrict procedure
pointers from being returned into a broader scope than the one in
which they're defined.  Such restrictions detract from the worth of
procedure pointers in Ada, though, and they also complicate the
semantic processing that compilers must perform.  So you do pay
prices.

In any case, I agree that the problems which crop up when consider-
ing adding procedure pointers to Ada aren't insurmountable.  I still
doubt that these problems are really worth tackling in the first place.
Your use of procedure pointers to limit scope is hardly the only way
to do so without resorting to the use of "globals"...