General HydroStatics
Ship Stability Software
Command of the Week
(New or interesting aspects of GHS that you may not know about)

A Modular Advantage


As your run files become more complex, you run the risk of unintended variable conflicts, especially if you favor short, generic variable names.

Let's say you have a macro that defines and uses i as a variable name for a counter or index of some kind. There is a way you can easily execute that macro and guarantee that it will not redefine the value of the variable i that was defined elsewhere and holds a value that is still in use: run the macro in a module.

Nice in theory, but rather cumbersome on practice you say? Let's see how easy we can make it.

How about a little interface macro that you execute, which in turn sets up the module and executes the macro you give it. We want something simple and easy to use, like

.INMOD "macname", parameter list

What INMOD will do is create a temporary run file with the macro definition in it plus a command to execute the macro. Then it will run the temporary run file in a module. Any variables that your macro defines will remain local to that module and not interfere with variables outside the module. Of course you would not use this method for something that gets executed in a tight loop since it adds to the time it takes to execute the macro.

A likely question is, "Doesn't that isolate the macro? How can it access outside variables and other macros?"

The answer is, "No, it does not isolate the macro in that sense, because it still sees all the variables that are not within modules: it can access them and set their values just as it might have done outside of the module. The same is true of macros that are outside of the module. Whatever names are defined within the module get priority, but if a variable or macro name has been defined outside of any module, and there is no like name within the module, then the connection is made with the outside name."

Another likely question is, "Isn't my macro in two places because it exists both inside the module and outside?"

"That's true, but it does no harm unless you inadvertently execute it directly without going through INMOD."

"What happens to the module after that? Is it still there with my macro in it?"

"Yes, it's still there, and you could execute your macro directly by prefixing the macro name with the module name: for example, if the macro name is AMAC and the module name is INMOD, then to execute the macro directly the command would be .INMOD.AMAC followed by whatever parameters are needed."

It sounds like INMOD has a complicated task to perform, but it turns out to take only four lines:

MACRO INMOD
WRITE (MACRO) INMOD.$$$ /NAME:"%1*"
WRITE (LINE) INMOD.$$$ "END INMOD.%1 "%2", "%3", etc up to "%9"
RUN INMOD.$$$ /CALL:INMOD /QUIET
IF FEXIST INMOD.$$$ THEN ERASE INMOD.$$$
/

Don't be misled by the arbitrary name INMOD being used for the macro name, the temporary file name, and the module name. All three names could be different and it would work the same.

Notice that thanks to the END command executing your macro, the temporary file INMOD.$$$ does not remain open while your macro is being executed. It is best to check for its existence before erasing it, just in case someone has deleted it before your macro is through doing whatever it does.

Another thing to notice about INMOD is the asterisk it places after the macro name. The asterisk is not necessary if protection for the one macro is enough. The presence of the asterisk will pull in all macros that have the same initial characters in their names. This may or may not be a good feature. If you have several macros that work together and are purposely named with the same leading characters (and no other macros outside of that select group happen to have those same leading characters), then it's a good feature. Note that the macro that gets executed first is the one with the shortest name!

Modules remain in existence during the GHS session. To modify the contents of a module, you have to put the commands in a run file as INMOD does. If you want INMOD to clear macros and variables from the module before executing your macro, use this version:

MACRO INMOD
IF FEXIST INMOD.$$$ THEN ERASE INMOD.$$$
WRITE (LINE) INMOD.$$$ "CLEAR (*) VARIABLES | CLEAR (*) MACROS
WRITE (MACRO) INMOD.$$$ /NAME:"%1*" /APPEND
(the rest is the same)

Modules can only be deleted by exiting GHS and bringing it up again. But why would you want it any other way?


Questions, comments, or requests?
Contact Creative Systems, Inc.

support@ghsport.com

USA phone: 360-385-6212 Fax: 360-385-6213
Office hours: 7:00 am - 4:00 pm Pacific Time, Monday - Friday

Mailing address:
PO Box 1910
Port Townsend, WA 98368 USA

www.ghsport.com

Click here for an index to this and previous COWs