Dunbaratu
commented
10 years ago I'm now of two minds about this. I can see people wanting to rely on this behavior (that the when/thens get removed at program end) since there's no ability to explicitly remove a when/then once it's been set up.
Basically the only reason I wanted this was because there's a Klein-bottle problem in the way the when/then syntax currently works that makes it impossible to re-instantiate a when/then from inside itself without nesting the entire body again inside itself X number of times deep to be able to re-enable the trigger X times. If you want it to be able to re-trigger itself 50 times, you have to nest it inside itself 50 levels deep, for example. And this is all because you can't name the 'when/then' and say "set that one up again". I was trying to get around it by making the when/then inside a program file and then have the program file recursively re-call itself to re-insert itself. But perhaps the real solution is just to have a way to state "this when/then is meant to repeat" when first making it.
Perhaps a syntax construct like WHENEVER blah THEN { blah }.
JoCRaM
WHEN/THEN's and ON's are removed when exiting a program, but I think they should be actually only removed when exiting all the way back to interactive mode. The way it stands now, they appear to be removed a the end of any program even if it's a program called from another program. If program A calls program B, and program B sets up a WHEN/THEN or an ON condition, then when program B hands control back to program A, the WHEN/THEN or ON is gone.
I was trying to make a recurring WHEN/THEN this way, but it doesn't work because of that.