On Feb 17, 11:54=A0pm, Aaron Seidman
> On 18-Feb-10 12:39 AM, Maury Pepper wrote:
>
> > "Aaron Seidman"
> > messagenews:4B7CCED4.8020607@imaginativehyphenillustration.com...
> >> On 17-Feb-10 11:05 PM, lenrek wrote:
> >>> On Feb 17, 4:18 pm, Aaron Seidman
> >>> wrote:
> >>>> IF
> >>>> *(execute dotted code that follows this line)
>
> >>>> In M logical tests, a zero value is interpreted as false and a non-z=
ero
> >>>> value is interpreted as true. The result of the most recent test is
> >>>> preserved in a special variable, $T. The IF at the end of the line
> >>>> insures that whatever happens in the course of calling subroutines,
> >>>> when
> >>>> the current line exits, $T will be 1.
>
> >>>> Aaron
> >>>> --
> >>>> Aaron's Axiom: Knowledge increases linearly, ignorance increases
> >>>> exponentially
> >>>> --
>
> >>>> lenrek wrote:
> >>>>> Occasionally I'll see statements in some code like
>
> >>>>> i $d(vals)>0 d i 1
> >>>>> . code here
> >>>>> . code here
> >>>>> .. more code
> >>>>> etc
>
> >>>>> What $d is unimportant, I'm just wondering what the "d i 1" actuall=
y
> >>>>> means. Can anyone answer?
>
> >>> So it would seem a little superfluous and serving almost no purpose.
> >>> Generally I woulhdn't want the dotted code to execute unless the if
> >>> condition was true. It seems like it's just ensuring that the dotted
> >>> code always runs. Unless I'm missing something?
>
> >> The reset of $T takwes place AFTER the dotted code runs. When that
> >> line completes the interpreter skips to the first line after the dots.
> >> The dotted code is completely ignored if the first condition is not
> >> met. The idea is that if the dotted code calls an external subroutine
> >> that has a test that changes $T, the final IF resets it. That way, any
> >> other code that is also dependent on the results of the first
> >> condition will run as well.
>
> >> For example:
>
> >> IF
> >> ELSE
>
> >> If $T is 0 (false) the ELSE line will execute. The IF 1 will only get
> >> run when the initial IF
> >> value it had when that test was done should it have been changed
> >> because of another test in the subroutine.
>
> > Aaron's example is on target assuming that
y
> > label and not an argumentless DO because $T is stacked when an
> > argumentless DO is called. In the original example, the IF 1 is
> > unnecessary because you could not get to that point unless $T was
> > already 1. It might change during execution of the dot levels, but when
> > execution resumes at the no-dot level, $T will be restored to 1.
>
> > The classic IF THEN ELSE found in some other languages can be done in
> > Mumps as:
> > IF condition DO
> > . code to execute if condition is true
> > ELSE DO
> > . code to execute if condition is false
> > ; at this point, the value of $T is based on the initial IF and not on
> > any intervening code.
>
> Maury's example is what good programming practice looks like, but one
> comes across all kinds of code in actual applications...
>
> There is one condition under which IF 1 could be necessary: although one
> cannot exit arbitrarily from an argumentless DO, it is possible to call
> an external (to the DO) subroutine that contains a test that would not
> be stacked. I've seen even worse code than that in some legacy apps.
Okay, that clears it up. I just wondered if there was really any
purpose to it in my original example that I wasn't seeing. Thanks guys.