comp.lang.ada
 help / color / mirror / Atom feed
From: andy@Shasta.UUCP
Subject: Re: Procedure/function parameters
Date: Mon, 21-Jul-86 20:31:07 EDT	[thread overview]
Date: Mon Jul 21 20:31:07 1986
Message-ID: <685@Shasta.STANFORD.EDU> (raw)
In-Reply-To: 4700072@ada-uts

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.

      reply	other threads:[~1986-07-22  0:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1986-07-15 17:46 Procedure/function parameters andy
1986-07-19 19:46 ` richw
1986-07-22  0:31   ` andy [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox