Make obligatory the '#' postfix for Macro input params

[Psychophanta]

Code: Select all

Define .f
v=1.0
Macro ma(v=2.0)
  Debug Pow(v#,v)
EndMacro

ma()

Making it obligatory, the versatility AND readability is bigger. Guarranteed!
Do you see what i mean? :roll:
Else, there is impossible to access to a Global variable inside a Macro if the variable is defined with the same name for the input parameter in the macro.

[freak]

You are the only one i have seen putting a # behind every macro parameter.
I think it is a very weird thing to do (as the # is the concatination operator for macros, not a parameter postfix)

I don't think this is a good idea.

[Fred]

It's way too ugly ! Don't mess with global var in your macro..

[Psychophanta]

It's way too ugly !

For stuff inside a macro i find not so ugly. :roll:

Don't mess with global var in your macro..

Ooh!
Mmmmh... ok for Globals!
But also for constants?

Code: Select all

#var=16.0
Macro ma(var=1)
  v.f=1+#var
  Debug v
EndMacro
ma()

[Fred]

# is already used in the macros to join 2 parameters together.

[Psychophanta]

All right, i know, but how to achieve the #var constant inside the macro in the above example?

[Demivec]

Code: Select all

#var=16.0
Macro ma(var=1)
  v.f=1+#var
  Debug v
EndMacro
ma()

All right, i know, but how to achieve the #var constant inside the macro in the above example?

Since you know #var is a constant that you are referring to in the macro, choose the name of the macro's parameters so they don't match the constant's name. Instead of var choose vari, ,variable, etc. For example, if the constant was named #optionNum, you wouldn't use any parameters called optionNum.

This works:

Code: Select all

#var=16.0
Macro ma(vparam=1) 
  v.f=1+#var+vparam
  Debug v
EndMacro
ma()

[Psychophanta]

@Demivec, sincerely that is what is called a limitation of the language, in this case PB language, are not you in accordance?
Simply my request is to avoid limitations as much as posible.

I don't think this is a good idea.

I think it is a worthwhile to think at least twice about it, else think about another strategy to make to be "local" (Protected) to the input variables in a Macro, i.e. to be able to access to external variables and Constants from inside a Macro which has the same names as input parameters.

In Procedures there is different external and local variables, even they have the same name. My purpose is to allow it for Macros too.

[djes]

I agree with Psychophanta, there should be a syntax to distinguish macro parameters from others variables declared elsewhere. Or at least there's must be an alert when compiling, or a "good syntax rule" in the doc (naming macro parameters starting with "m_" for example).

The reason is that macro are often used in include files, and you just forget them after a while. I imagine that it could create bugs really difficult to find.

[Demivec]

@Demivec, sincerely that is what is called a limitation of the language, in this case PB language, are not you in accordance?
Simply my request is to avoid limitations as much as posible.

freak wrote:
I don't think this is a good idea.
I think it is a worthwhile to think at least twice about it, else think about another strategy to make to be "local" (Protected) to the input variables in a Macro, i.e. to be able to access to external variables and Constants from inside a Macro which has the same names as input parameters.

In Procedures there is different external and local variables, even they have the same name. My purpose is to allow it for Macros too. Smile

I am in accordance with you that it is a limitation. I am also in accordance with the language limiting it as a way to accomplish something. Limitations are not necessarily bad (but that's another matter ).

In this instance the limitation is that a programmer has to use a parameter name for the macro that doesn't match a declared constant if the constant is used in the Macro. IMHO this seems minor and nonprohibitive for the various uses of a Macro. Or in otherwords if an individual wanted to use a parameter and constant of the same name in a Macro they are mis-using the tool. Sometimes you can get a screwdriver to function as a hammer and sometimes not, better to use a hammer.

I realize that the limitation that may be the one actually being argued over is one of having the ability to write code that works within the bounds of the language as it currently exists. That is why almost everyone visits/contributes to the forum.

I am all in favor of removing needless limitations but I don't think you will prevail on the points you have expressed. Notwistanding that view, I'll wait and see if you sway Fred or freak.

[freak]

I don't see the problem really. It is just like with procedures.

In procedures, if you reuse a global variable (not as a parameter and without protected),
you are referencing the global variable. Same thing happens with macros.

In a procedure, if you reuse the global variable name inside a procedure as a parameter
or with protected, it will not use the global one, and you have actually no more a way
to access the global variable from inside this procedure (as the name represents the local variable then)
The same thing is with macro parameters that have the same name as a variable used elsewhere. makes perfect sense.

You always have to make sure you do not reuse the same name for different purposes.
That is a problem that exists in every language, not just in PB macros.
You can't just name all your global variables "var" and expect to get no conflict.
Choosing descriptive names solves this problem easily.

[djes]

it will not use the global one

Said that way, it's OK for me Don't remember if it's in the doc?

[Psychophanta]

I want to use a macro to assign a value to a variable:

Code: Select all

Macro m(a=200)
  a=a#
EndMacro

m()

It does not work.
That means i am forced to use another variable name different than the macro parameters? YES.
Very bad.

[Little John]

That is a problem that exists in every language, not just in PB macros.
You can't just name all your global variables "var" and expect to get no conflict.
Choosing descriptive names solves this problem easily.

I agree.
In this context, I just have to post a link to an article about The world's two worst variable names.

Psychophanta, you can easily avoid such conflicts by certain coding habits, e.g. never using a trailing underscore for constant and variable names, and always using a trailing underscore for macro parameters. The following works fine:

Code: Select all

Macro m(a_=200)
   a = a_
EndMacro

m()
Debug a

Regards, Little John

[Psychophanta]

I know, but you can not refuse the fact that it is a restriction of the language which i think could be avoided. :roll: