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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!csd4.milw.wisc.edu!bbn!gatech!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Procedure types and dynamic binding
Message-ID: <4078@hubcap.UUCP>
Date: 12 Jan 89 19:09:12 GMT
References: <8178@aw.sei.cmu.edu>
Sender: news@hubcap.UUCP
Reply-To: billwolf@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From article <8178@aw.sei.cmu.edu>, by firth@sei.cmu.edu (Robert Firth):
> There is just one problem with procxedure variables that has not
> quite been completely solved.  It is illustrated by this:
> 
> 	type proc_type is procedure;
> 
> 	procvar : proc_type;
> 
> 	procedure outer is
> 	  X : integer;
> 
> 	  procedure inner;
> 	  begin
> 	    X := X+1;
% 	  end;
% 
% 	begin
% 	  procvar := inner;
% 	end;
% 
% 	outer;
% 	procvar;
% 
% The final statement invokes the value of procvar, which is, of course,
% "inner".  The call of inner references the variable X declared in outer,
% which no longer exists.  This is the equivalent of the "dangling reference"
% problem when the address of a local variable is assigned to a global
% pointer.
% 
% Many solutions have been proposed; the cleanest in my opinion is that of
% Modula-2, which does not allow an "inner" procedure to be assigned to a
% variable.  If that were combined with reasonable visibility rules (so
% that a procedure could be unnested without perforce being made visible),
% I think it would be a definitive solution.

     Why not something along the lines of the "restricted" clause present
     in Preliminary Ada?  Then inner's specification would require that
     an integer named X be visible in the environment; the attempt to call
     procvar would then result in an error which would be similar to 
     a "missing parameters" situation.  This would have the added benefit
     of completing the idea of a specification such that ALL interactions
     between a procedure and its environment are fully documented (and
     compiler-enforced) in the specification, considerably simplifying
     program debugging and maintenance.

     Also, since Barry was unable to give an answer, for what situations
     would the use of procedural variables be intuitively natural and
     necessary?   Just some example of a realistic applications program
     for which current Ada would prove inadequate, some motivating reason
     for wanting to have procedural variables which would justify such
     a change.

     By the way, would this extend also to packages?  Package variables? 



                                        Bill Wolfe

                                 wtwolfe@hubcap.clemson.edu