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 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!topaz!ll-xn!mit-amt!mit-eddie!genrad!decvax!decwrl!glacier!Shasta!andy From: andy@Shasta.UUCP Newsgroups: net.lang.ada Subject: Re: Procedure/function parameters Message-ID: <685@Shasta.STANFORD.EDU> Date: Mon, 21-Jul-86 20:31:07 EDT Article-I.D.: Shasta.685 Posted: Mon Jul 21 20:31:07 1986 Date-Received: Wed, 23-Jul-86 04:33:11 EDT References: <679@Shasta.STANFORD.EDU> <4700072@ada-uts> Reply-To: andy@Shasta.UUCP (Andy Freeman) Organization: Stanford University Summary: Correct implementation is important List-Id: In article <4700072@ada-uts> richw@ada-uts writes: [I sketched a program that illustrated how procedure parameters make it possible to maintain separate scopes for things that should be separate, unlike the enumeration method. In his reply, he wrote a program where one procedure returns a local procedure that will modify a local variable of the original procedure if it is ever called. He then concludes with:] >The question is: What in the WORLD happens when someone tries to >call the result of function A? You don't REALLY want to be able to >modify the stack-frame of a procedure that has ALREADY RETURNED, now >do you? ESPECIALLY since by the time you call that result of function >A, there might be other data in the stack which has NOTHING to do >with "local_variable". (You C programmers out there -- ever been >bitten by this sort of bug when you return a pointer to a variable >in the stack? Damn hard to track down, isn't it?) > >This illustrates that, if pointers to subprograms were added to Ada, >only pointers to "outer" or "first level" subprograms could be valid >subprogram pointers. The price that Ada would pay if pointers to >nested procedures COULD be used would be a price in safety and program >correctness -- one of Ada's MAJOR design goals was to provide a safe >language. So, in order for you counter-example to be used as an >argument for adding procedure passing to Ada, one must concede that >Ada would also become less safe. Oh well... > >-- Rich Wagner Wrong conclusion. If a language allows the program you describe then any implementation that behaves the way you're worried about is wrong. (In C, returning a pointer to a variable on the stack is an error. C isn't required to detect this error, but C isn't an example of a safe language.) If a language makes it possible to RETURN procedures, then an implementation must be able to heap-allocate activation records. (Note the difference between "be able to" and "always".) Some Extended Pascal dialects allow procedures as PARAMETERS, but not values (you can't put them in records or variables); their implementations can stack-allocate activation records without running into the problem you describe. If the language also requires proper declarations of these parameters, the language will be type-safe. If you've written large programs, you know how important it is to maintain the appropriate scope, as defined by the problem. That isn't an issue in small programs. (Ada is supposed to be good for large programs ....) BTW - there are languages where a procedure can return multiple times. Some of them even allow stack-allocation of activation records; you just have to be careful when you pop. -andy decwrl!glacier!shasta!andy andy@sushi.stanford.edu ps - I think it is bad style to use scoping that is wider than necessary. Procedure as parameters (and as values) are one tool to help me; you can use all globals if you prefer.