Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!plus5!hokey
From: hokey@plus5.UUCP
Newsgroups: comp.std.mumps
Subject: Possible solution to $T stacking on DOs
Message-ID: <1727@plus5.UUCP>
Date: Sun, 26-Apr-87 16:42:12 EDT
Article-I.D.: plus5.1727
Posted: Sun Apr 26 16:42:12 1987
Date-Received: Sun, 26-Apr-87 23:55:23 EDT
Sender: hokey@plus5.UUCP
Lines: 52
Approved: hokey@Plus5.Com
Volume-Issue: X11/1987.06/comp.std.mumps/3


I have a possible solution to the problem of stacking $T.

Specifically, upon entering a DO/XECUTE level, $T is stacked iff it has
a defined value.  As DO/XECUTE levels are popped, $T is restored only if
it was saved.

Additionally, permit "KILL $T" (as a means to "undefine" $T).

While this is a slight incompatibility with old code, there is a trivial
way to change the exceedingly rare cases in which software depended on
$T being set in a subroutine.  It is equally trivial to handle the case
in which the subroutine needs to know the "current" value of $T at its
entry, and modify $T at exit.  Examples follow:

	Only want $T at exit:

		;Old code:
		do subr set flag2=$t

		;New code:
		kill $t do subr set flag2=$t

	Subr needs $T at entry, returns "different" $T at exit:

		;Old code
		;$T contains "good stuff"
		do subr
		set flag2=$t
		...
	subr	;
		...

		;New code
		;$T contains "good stuff"
		goto cs1:$t
		k $t d subr0 goto csret
	cs1	k $t d subr1
	csret	set flag2=$t
		...
	subr0	if 0
		goto subr
	subr1	if 1
	subr	;
		...

I have no intention of turning this into a proposal.  If somebody else likes
this approach enough to do so, that's fine with me.

Note that this proposal can obviate the need for special language with
"block structure" which handles $T stacking.

Hokey