[comp.lang.modula3] Local procedure assignment

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.