Nested and Conditional Subroutines - NOT

[gdyvig]

Occasionally you see script examples of a Subroutine nested inside another perhaps within some conditional code. This can lead to a misunderstanding of how subroutines work in Macro Scheduler.

All Subroutines are loaded before any code is executed. It does not matter where they are located. A subroutine should be defined only once, even if multiple versions are embedded in conditional code.

Example1:

Code: Select all

Let>var=0
SRT>SRT1
   if>var=1
      SRT>SRT2
          MDL>I'm in SRT2
      END>SRT2
      GoSub>SRT2
   else>
      MDL>I'm not in SRT2
   endif
END>SRT1
GoSub>SRT1

Example2:

Code: Select all

Let>var=0
SRT>SRT1
  if>var=1
      GoSub>SRT2
  else
      MDL>I'm not in SRT2
  endif
END>SRT1

SRT>SRT2
   MDL>I'm in SRT2
END>SRT2
GoSub>SRT1

The code in Example1 and Example2 is equivalent.


Gale

[Marcus Tettmar]

Not entirely true - they are not *loaded* before code is executed. But it is true that it doesn't matter where they are. Subroutines are not *loaded*, but they are only executed when called. When not called they are simply skipped - ignored if you will. Therefore there is nothing to lose by having them in repeated blocks of code. This is just a matter of taste. No gain or loss either way.

[gdyvig]

And for that reason this will not work:

Code: Select all

Let>var=0
SRT>SRT1
   if>var=1
      SRT>SRT2
          MDL>I'm in SRT2 v1
      END>SRT2
      GoSub>SRT2
   else>
      SRT>SRT2
          MDL>I'm in SRT2 v2
      END>SRT2
      GoSub>SRT2
   endif
END>SRT1
GoSub>SRT1

Regardless of the value of var, the 1st version of SRT2 will execute.


Gale

[Marcus Tettmar]

That's true, because the script is scanned for the subroutine from the top down. So duplicate subroutines don't do anything. Only the first will be seen.

Slightly different issue to what I thought you were saying - I thought you were advocating not having subroutines inside other subroutines. That itself is not an issue. But certainly having more than one copy of a subroutine inside nested logic won't work - only the first will be seen - and the logic won't effect whether or not a subroutine is seen because it is not executed. It is sought when required and it doesn't matter where it is the first occurrence will be used.

[jpuziano]

That's true, because the script is scanned for the subroutine from the top down. So duplicate subroutines don't do anything. Only the first will be seen.

Since having more than one subroutine with the same name is "not advisable" (a programming error really)... I am still pulling for the enhancement below:

[Open] Can GoSub throw error if duplicate Sub names found?
http://www.mjtnet.com/forum/viewtopic.php?t=4585

and this related enhancement:

[Open] Warn and/or Prevent entry of Duplicate Labels
http://www.mjtnet.com/forum/viewtopic.php?t=5980

With the above enhancements, the MS editor wouldn't let us save the script with these errors present.

Take care

[Marcus Tettmar]

Since MacroScript is interpreted it reads one line at a time. To have a warning/error about duplicate subroutines it would have to read EVERY line of code to do so when a sub is called, or on startup at least. I personally think this is wasteful. I suppose it could be switched on and off. Frankly I don't believe this is a huge problem worth spending much time to solve. But ....

[jpuziano]

Since MacroScript is interpreted it reads one line at a time. To have a warning/error about duplicate subroutines it would have to read EVERY line of code to do so when a sub is called, or on startup at least. I personally think this is wasteful.

- I suppose it depends on how much extra time it took. An extra 0.1 sec probably wouldn't be missed... but if it tacked on 5 seconds... even 1 second... that could mess things up for people who need things to execute quickly.

I suppose it could be switched on and off.

- I hadn't thought of that... that's actually a great idea. You could call it "strict" mode. If on, then on startup it would run whatever extra checks needed to make sure there are no duplicate labels, subroutines, or whatever you eventually add to the list of things to check for.

Frankly I don't believe this is a huge problem worth spending much time to solve. But ....

- ...but the Include> statement makes this a problem worth looking into... because we can pull in other scripts into our main script. What if the included script contains a Label that is exactly the same as a Label we already have in our main script? From regular reading of these forums, I think that when a label is called, it starts from the top of the script and scans for that Label. There are now two of them. Which one is it going to find first? Who knows... the macro may keep working fine or it may start misbehaving... but there is no error message to tell us what happened... and I wish that there was.

- I think this is a problem worth solving... does anyone else agree?

[gdyvig]

Another variation of the switch it on/off is to do the extra checks only when the script editor is open. That gives you a chance to get it right and not have the overhead when running it normally.

I think this kind of problem is most likely to occur in shops with several developers sharing the same include scripts.


Gale

[jpuziano]

Another variation of the switch it on/off is to do the extra checks only when the script editor is open. That gives you a chance to get it right and not have the overhead when running it normally.

- Yes, I think I mentioned this in one or both of the Enhancement requests... If this kind of checking were added, the first and lowest overhead place to add it would be in the MS Editor. It could check when we save the script and if it found two labels or subroutines with the same name, it could pop up error details and not allow the save unless the error is fixed.

- One step better than that would be if the MS Editor, as you're typing up a script, keeps track internally of all labels and subroutine names used so far. That way, as soon as you enter a Label that has already been used elsewhere, it could notify you of the problem and you could fix it right away.

I think this kind of problem is most likely to occur in shops with several developers sharing the same include scripts.

Yes, and even when only one developer is using Include scripts. Note that variable Scope is being introduced with version 12 to encourage and facilitate using include scripts. If my included scripts are large and contain many labels and subroutines, I'd like a way to not have to manually check for collisions with any labels and subroutine names I may have used in my main macro.

Just my two cents... take care.