modula-3@uni-paderborn.de (Thomas Roemke) (04/10/91)
Assigning a local procedure is illegal. In the case of procedure variables the compiler has to generate code for verifying this at runtime. The pro- gram below has to raise an exception (or just terminate execution??), since the second assignment to x is illegal (i.e. a local procedure). Am I right ? MODULE LProcAssign EXPORTS Main; VAR x: PROCEDURE (); PROCEDURE q(p: PROCEDURE (); b: BOOLEAN := TRUE) = PROCEDURE z() = BEGIN END z; BEGIN x := p; (* runtime check (b = FALSE => runtime error) *) IF b THEN q(z,FALSE); (* correct, local z *) END END q; PROCEDURE z() = BEGIN END z; BEGIN q(z); (* correct, global z *) END LProcAssign. Thomas -- (* Thomas Roemke, University of Paderborn, Germany modula-3@uni-paderborn.de ..!uunet!mcsun!unido!pbinfo!modula-3 *)
kalsow (Bill Kalsow) (04/12/91)
> Assigning a local procedure is illegal. In the case of procedure variables > the compiler has to generate code for verifying this at runtime. The pro- > gram below has to raise an exception (or just terminate execution??), since > the second assignment to x is illegal (i.e. a local procedure). Am I right ? Yes, the second assignment 'x := p' where p = q.z is a checked runtime error. The Modula-3 Report does not specify the behavior of a checked runtime error. SRC Modula-3 terminates with a core dump (or at least it should) on all checked runtime errors. - Bill Kalsow
kalsow (Bill Kalsow) (04/16/91)
I tried Thomas Roemke's program here. The compiler doesn't generate the correct code when it calls "q(z,FALSE)". Since the local procedure q.z doesn't depend on any values in its parent's frame, the compiler decides that it can be passed like a top-level procedure. This is a bug. Adding "VAR zb := b;" as a local declaration in q.z causes the compiler to emit the correct code. Thanks for the bug report. - Bill Kalsow.