Path: utzoo!attcan!uunet!mcvax!ukc!icdoc!dcw From: dcw@doc.ic.ac.uk (Duncan C White) Newsgroups: comp.lang.modula2 Subject: Re: procedure variables (ca. 80 lines) Summary: Fourth possibility Message-ID: <784@gould.doc.ic.ac.uk> Date: 26 Apr 89 18:05:09 GMT References: Reply-To: dcw@doc.ic.ac.uk (Duncan C White) Organization: Dept. of Computing, Imperial College, London, UK. Lines: 72 In article Modula2 List 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...