🚀 go-pugleaf

In article <INFO-M2%89042509041995@UCF1VM> Modula2 List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes:
>   Why not allow local procedures? Simple: because it's NOT simple :-)
{discussion of a rather trivial problem deleted: onto the real problem}

>   Suppose the following:
>
>   VAR v: PROCEDURE;
>   PROCEDURE A;
>     PROCEDURE B;
>     BEGIN END B;
>   BEGIN v:=B; END A;
>
>   BEGIN A; v(); END;
>
>   Where's my stackframe gone to???

{3 approaches:}

>   First, ISO Pascal. We do not allow procedure variables, except as
>   parameters. Obviously, the stack frame will thus be there.

>   Second, Lisp. The stack frame is an (invisible) Lisp object.
>   As long as there exists a procedure variable pointing to X,
>   the garbage collector will not kill the stack frame for that
>   invocation of X's parent. Obviously, stack frames are heap objects
>   chained with pointers. Nice but SLOWWWW.

This sounds very dangerous to me: it allows procedure B to examine and
modify the outer-scope variables of the defunct procedure A, even though
these variables cannot be accessed by anyone else!

>   Of course, there is always a third way: don't allow this. Modula-2.

There is a 4th way: this hinges upon the observation that it MAY
or MAY NOT be safe to do this.. it's a bit draconian to ban it always
just because it may not be safe.
(Comparison, let's ban division because division by 0 is unsafe!)

So, let us ask ourselves: when does the problem actually occur?

Well, I reckon that it's a certain kind of CALL which causes the problem:

	A CALL (thru a procedure variable) to a procedure whose static
	outer procedure is NO LONGER on the call-chain.

A solution to this problem is know looking irrestibly like a run-time check
(just like division!) : when a call-thru occurs, check that the outer
procedure is still activated.

This check is only needed for procedure-variables which have local-procedures
assigned to them - a property which may be determined at compile-time.
Hence only users wishing to assign local procedures to procedure-variables
would suffer any slowdown on procedure-variable calls.

Of course, I guess Wirth couldn't be bothered with this, so took the simple 
way out: BAN IT.

Anyone know of compilers which make this extension?

>Kai
>
>onm64 @ dmswwu1a . bitnet


	Duncan.

[ Reply to: dcw@doc.ic.ac.uk or ...!ukc!icdoc!dcw ]
----------------------------------------------------------------------------
Duncan White,           |       "Middle East Policy was a fiasco and a
Dept. Of Computing,     |       disaster, but Central American policy was
Imperial College,       |       in better shape - it was merely a disaster!"
London SW7, England     |                  Spitting Image on Reagan...