Global Variable Question

[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

[DonStauffer]

@gloomyandy C++ has something like Pascal has, in that you can create local constructs within a function, and the function becomes the enclosing scope and so is accessible. It's been too long and I don't remember the details.