Global Variable Question

DonStauffer

In addition to being global in scope, it seems global variables persist beyond the end of the macro which created them. Perfectly reasonable and useful behavior.

It does bring up the question of how one might "delete" a global variable programmatically, rather than simply setting it to 0 or "". I wonder if there is a command which "undoes", for instance:

global XXX = 3

So XXX doesn't exist, as before.

fcwilt

@donstauffer said in Global Variable Question:

In addition to being global in scope, it seems global variables persist beyond the end of the macro which created them. Perfectly reasonable and useful behavior.

It does bring up the question of how one might "delete" a global variable programmatically, rather than simply setting it to 0 or "". I wonder if there is a command which "undoes", for instance:

global XXX = 3

So XXX doesn't exist, as before.

Why would you need to delete a global variable?

Thanks.

Frederick

DonStauffer

@fcwilt At the moment, so I can create it automatically each time the macro runs. For a macro system you'd like to distribute to other people, you don't want to have it generate an error every time you run it, or require that they do a one-time initialization. I have one such system that can generate multiple instances of the system in different subdirectories, so any given run of the install won't necessarily be the first, but might be.

And turning off the machine erases globals, so on any given run of a macro you don't know if they exist or not. You could run a creation macro from config.g, I guess, but I'd rather not get into modifying config.g if I can avoid it.

And right now exists() always returns False.

Also reduces clutter because globals are still around after you're done with them. For some purposes, that's what you want. For others, not especially.

DonStauffer

@fcwilt Primarily, I was looking for a current workaround for exists not yet working.

DonStauffer

@fcwilt I must have been doing something wrong. exists does work after all. I think I had a typo. So, OK. I'll just check globals before I create them.

fcwilt

@donstauffer

So you create global vars in these macros.

How are they then used? What is the scope?

Thanks.

Frederick

DonStauffer

@fcwilt Scope is global but need not persist beyond the currently running print job, which called the macros. But it may call some more than once, including the ones that create the variables, and another print job (or the same one, being run again) could also end up running those macros again. So I did need a way to create them iff they didn't exist. The exists function makes it possible to do that but I mistakenly thought it wasn't yet implemented. Bad brain day.

fcwilt

@donstauffer

Thanks.

Would it be helpful to have a variable scope that would be visible to any macros called from the macro where the variable was created?

Frederick

DonStauffer

@fcwilt I assume you mean "but not in the scope that called the macro where the variable was created", since globals already are visible in both places. I can't think of a need for that which would not be covered by globals, except that it would be a bit neater not to have them hanging around after the macro finished unless needed.

fcwilt

@donstauffer said in Global Variable Question:

@fcwilt I assume you mean "but not in the scope that called the macro where the variable was created", since globals already are visible in both places. I can't think of a need for that which would not be covered by globals, except that it would be a bit neater not to have them hanging around after the macro finished unless needed.

I'm a retired computer programmer. The primary language I used (and still use) has a scope like I was thinking of.

To clarify just a bit it:

Macro A calls Macro B, which calls Macro C, which calls Macro D.

Macro B creates a variable with this scope.

Macros C and D can access the variable but Macro A cannot.

Frederick

DonStauffer

@fcwilt That was my assumption of what you meant. It might be useful, but remember some of the Duet boards have limited storage for the firmware. So having a compelling use case is necessary. It seems possible this could be a useful scope. At least it isn't "too global" as current globals seem to be for some purposes. But a simple dichotomy in variable scope keeps memory requirements down and covers most of the bases. I haven't been able to think of a need, but it's a reasonable concept and maybe there is one. When would you use a "semi-global" (downstream scope?) like that?

DonStauffer

@fcwilt Having now explored variables and pondered syntax and usage cases, I think I should say this: Between the addition of variables, conditionals, and loops, the macro capability of RRF just pulled a "Wizard of Oz" and went from black and white to Technicolor. So many things are now possible that just weren't before!

RRF 3.3 is profoundly richer than previous versions. Giant leap forward!

dc42

@donstauffer said in Global Variable Question:

And right now exists() always returns False.

Please explain what you mean by that. You should be able to use

exists(global.myvar)

to test whether a global variable has been created yet.

DonStauffer

@dc42 My testing in error. exists() works fine.

dc42

@fcwilt said in Global Variable Question:

Would it be helpful to have a variable scope that would be visible to any macros called from the macro where the variable was created?

That should already be the case for local variables created using var.

DonStauffer

@dc42

Macro "Caller":
var X = 3
M98 P"/macros/Test/Callee"

Macro "Callee":
echo "X="^{var.X}

Result of running Caller:
Error: in file macro line 1 column 17: meta command: unknown variable 'X'

(This is fine with me. As expected.)

fcwilt

@donstauffer said in Global Variable Question:

When would you use a "semi-global" (downstream scope?) like that?

If the development of "macro packages" were to become popular that kind of scope could limit the need for global variables and thus reduce possible conflict with other "macro packages".

Not a huge issue to be sure but if it was something that was fairly easy to do with no real downside it might be something to consider.

Frederick

dc42

@donstauffer said in Global Variable Question:

@dc42

Macro "Caller":
var X = 3
M98 P"/macros/Test/Callee"

Macro "Callee":
echo "X="^{var.X}

Result of running Caller:
Error: in file macro line 1 column 17: meta command: unknown variable 'X'

(This is fine with me. As expected.)

Thanks. I've added this to my list for checking, and to consider what behaviour is most desirable.

gloomyandy

@fcwilt I'm curious which programming languages allow access to local variables from other functions in this way? The only ones I can think of off the top are my head are ones like Pascal but in that case the procedure/function definition is within the same scope as the "local" variable and so makes more sense. Allowing dynamic access to local variables is not something I've come across.

fcwilt

@gloomyandy said in Global Variable Question:

@fcwilt I'm curious which programming languages allow access to local variables from other functions in this way? The only ones I can think of off the top are my head are ones like Pascal but in that case the procedure/function definition is within the same scope as the "local" variable and so makes more sense. Allowing dynamic access to local variables is not something I've come across.

Pascal (actually Delphi) as you have noted.

Since Delphi supports objects it also has the concept of object members/methods having private, protected and public scope.

A member/method with private access is accessible only from the class in which it is declared.

A member/method with protected access is accessible from sub-classes.

A member/method with public access is accessible from all other classes.

Frederick