Concat evaluates first parameter twice

[EricGB]

Hi,

Below I added 2 pieces of code.
The first one works very well, however, I try to minimize using VAREXPLICIT.
The second one, using the default VAREXPLICIT=0, comes up with something I did not expect.

Code: Select all

[color=green]//Snippet 1:
//Re-start here using <F8>
Let>VAREXPLICIT=1
let>a=b
let>b=c
let>x=%a%
//x == "b"
let>y=%b%
//y == "c"
concat>%x%,%y%
//x == "bc"   as expected

[/color]

Code: Select all

[color=green]//Snippet 2:
//Re-start here using <F8>
Let>VAREXPLICIT=0
let>a=b
let>b=c
let>c=d
let>x=a
//x == "b"
let>y=b
//y == "c"
concat>x,y
//x == "cc"!  Expected "bc" here, but variable x is translated twice
//                 here (x-->"b",  b-->"c")
//                 variable y is translated only once (y-->"c")
[/color]

Is there a logical explanation for this?

Regards, Eric.

[Marcus Tettmar]

Interesting. Not sure if there's a logical explanation or not until I've delved into under the hood. Concat isn't much used these days which might be why this hasn't been caught before - my preferred method of concatinating is like this:

Let>x=%x%%y%

The benefit here is that you can concat more than two items together, and specify the order, or even add strings in between etc ...

So that's your workaround - don't use concat. But we'll look into what's going on with concat anyway.

[Marcus Tettmar]

Ok, it seems concat is recursively resolving the first var as far as can be gone and since x=a and a=b and b=c x must be c. So we end up with cc.

Use Let> to concatenate instead.

[EricGB]

Ok, thanks for telling to not use concat.

So then I won't be hurt by next too:

Perhaps the use of the %-sign for the destination parameter of a concat-statement in the code below is not allowed/or not adviced, but a strange new variable is created after execution. Note that Macro Scheduler seems to get the value for the first parameter correctly, "tt", but it does not assign the totally correct result value "ttNN" to the variable efg[c].

Code: Select all

Let>VAREXPLICIT=0
let>x=C
//x="C"
let>y=NN
//y="NN"
let>efg[c]=tt
//efg[c]="tt"
concat>efg[%x%],y
//FG[%X% == "ttNN"!  The value is like I expected, 
//                   but why is the resulting value
//                   assigned to a variable named  "FG[%X%"?
//                   But it is probably not allowed to use a composite variable
//                   as a destination (because it is not a Let-statement, 
//                   which was stated by Marcus in earlier subjects).
let>q=FG[%X%
//q == "ttNN"  immediate value for  FG[%X%  found, so it is 
//                  apparantly used
let>r=FG[%X%]
//r == "FG[C]" immediate value for  FG[%X%]  not found, so translate
//                    embedded variables:
//             %X% --> "C"
//             then immediate value for  FG[C]  not found, so  FG[C]  
//             is the result.
let>s=EFG[%X%]
//s == "tt"    immediate value for  EFG[%X%]  not found, so translate 
//             embedded variables:
//             %X% --> "C"
//             then immediate value for  EFG[C]  found, so translated into  "tt".

Regards,
Eric.

[jpuziano]

Ahhh the intricacies of ConCat> variable resolution... Check this post for more:

Window title Separate by "x" oddity
viewtopic.php?p=16615

Take care

[EricGB]

Great you have found that too!
It matched perfectly with my first example.
And sorry for not finding your article from 3 years ago.

But besides the different number of resolving steps for the first and second parameter of the concat, another problem seems to be there in the code below:
(I tried to make no typos here, so please try to read it as it is)
The concat creates a totally unexpected new variable instead of assigning the result to the first parameter.
The first parameter is efg[%x%] (and x is "c"), so the expected destination variable would be efg[c].
But instead, a new variable is created with name
FG[%X% (yes, no closing "]", and where is the "E" and why is the %X% not resolved?)
What the concat does right, is taking the first part of the concatenation from variable efg[c], i.e. "tt".
Also the second part for concatenation is right and so is the resulting string: "ttNN".
But that result is not assigned to efg[c]! Instead it is assigned to a new variable with name FG[%X%

Try next code:

Code: Select all

Let>VAREXPLICIT=0
let>x=C
//x="C"
let>y=NN
//y="NN"
let>efg[c]=tt
//efg[c]="tt"
concat>efg[%x%],y
//FG[%X% == "ttNN"!  The value is like I expected, 
//                   but why is the resulting value
//                   assigned to a variable named  "FG[%X%"?
//                   But it is probably not allowed to use a composite variable
//                   as a destination (because it is not a Let-statement, 
//                   which was stated by Marcus in earlier subjects).
//  To prove that variable really seems to be present:
let>q=FG[%X%
//q == "ttNN"  immediate value for  FG[%X%  found, so it is 
//                  apparantly used

Did you discover this behavior already?

Regards, Eric.

[JRL]

But besides the different number of resolving steps for the first and second parameter of the concat, another problem seems to be there in the code below:

Look HERE for your answer.
You can get odd results if you are not careful about how you use percents within a variable name. Using percents as part of the variable name does not work with most Macro Scheduler functions. As far as I know, only the Let> function allows percents in a variable name creation.

Code: Select all

let>x=C
//x="C"
let>y=NN
//y="NN"
let>efg[c]=tt
//efg[c]="tt"
Let>value=efg[%x%]
Let>efg[%x%]=%value%%y%

Great you have found that too!
It matched perfectly with my first example.
And sorry for not finding your article from 3 years ago.

The primary message from the excellent jpuziano post is DON"T USE SINGLE CHARACTER VARIABLE NAMES. I don't know how many times I've said that here on the forum and to people I work with.

Concat isn't much used these days which might be why this hasn't been caught before - my preferred method of concatinating is like this:

WHAT! I use concat all the time. Its NEVER failed me

As for your initial post. If you use incorrect syntax you never know what anomalies might occur. You are setting text characters to other text characters rather than setting variables to other variables. As I see it, correct syntax would provide a fully resolved set of variables and you would end up with a concated variable "x" with a value of "dd"

Code: Select all

//Re-start here using <F8>
Let>VAREXPLICIT=0
let>c=d
let>b=c
let>a=b
let>x=a
//x == "d"
let>y=b
//y == "d"
concat>x,y
//x == "dd"!  Expected "dd" here.

I'm a little curious as to what possible purpose could be served by creating a slew of variable names all with the same value. Can you post the program you are having problems with or perhaps a functional sample? Sometimes isolating the issue as you have done is not as useful as seeing the original program. Someone might be able to suggest a completely different and workable method to accomplish your task. Gettiing the job done is, after all, the ultimate goal.

[EricGB]

About the concat: I will follow your hint of not using percent-signs at the position of the destination variable, thanks. Excellent example of yours by the way about assigning a value to "nul"!
Single character names: you are totally right, in my daily work I never use these! But in my example I used them for keeping the code compact. I focussed on the way Macro Scheduler resolves variables and performs assignments in different cases. I thought as long as I don't know the exact behavior of it in several "basic" examples, I might end up with code behaving differently from the expected. In order to prevent this, I made these posts.
The given examples were actually created based on problem I had in one of my Macro Scheduler scripts, but were reformed from the script such that they show the real "pain". I intentionally wrote the statements in that sequence.
I also want to use the knowledge of Macro Scheduler behavior for making a decision in my project - automation of a rather complicated digital TV signal processing setup - about which parts of it can be done in Macro Scheduler, and which parts are better left up to e.g. python.

And finally I tell you I get a comfortable feeling on this forum that people with knowledge give their helpful replies. So thank you for your efforts!