Zugg Software :: View topic - [2.07] Local variable appending not working correctly

Novice Joined: 23 Jun 2005 Posts: 32

I found a fun little bug in local variables.

Any alias which assigns to another variable in this manner has the problem.

To replicate, make an alias with a named parameter. For example:

Posted: Sat Oct 20, 2007 5:49 pm

Confirmed. It seems to be something to do with the implicit concatenation. This is in my mind a "grey area" bug. It doesn't work like one might expect. But Zugg has often warned of the odd results of implicit concatenation.

Novice Joined: 23 Jun 2005 Posts: 32

Well, I can see it just NOT WORKING and trying to make a variable called "test$foo", but appending some weird number is OBVIOUSLY not a feature. Razz

Posted: Sat Oct 20, 2007 8:24 pm

I agree with Tech and I don't think Zugg will disagree either, you have to use the concat.

Novice Joined: 23 Jun 2005 Posts: 32

If I need to use %concat, then please explain why #variable test@{variable} works fine, but #variable test${localvar} doesn't. I'm just trying to nail down if it's a bug that I get random numbers, a bug that it does even try to concat, or what.

Posted: Sat Oct 20, 2007 9:05 pm

I believe the number is because local variables are indexed using a number. Normal variables aren't, that's why it works. If CMUD were going to be very strict, it wouldn't work, but it does.

Novice Joined: 23 Jun 2005 Posts: 32

Fair enough - now, is there a workaround? I use this functionality quite a bit, so I'm wondering if there's any shortcut (for example, "string" . $var . "string") other than %concat("string",$var,"string").

Enchanter Joined: 09 Sep 2007 Posts: 605

I think Fang is right. The numbers is not random, they go in a sequence, because your local vars was created one after another.

P.S. Hmm, I can't get command history in untitled session by pressing the UP key, only through history drop-down list. Is it a feature?

Novice Joined: 23 Jun 2005 Posts: 32

Interesting other development: it works with other implicit concatenation.

For example:

Posted: Sat Oct 20, 2007 10:36 pm

It's presumably because the #var command can also be used to edit the value of a local variable, which is why the name of the local variable in the name parameter of the #var command is expanded into its reference number. #exec only ever expands variables to their values, so it's not ambiguous.

A slightly shorter way, if you really want one, would be to use ("something" + $var).

Posted: Sun Oct 21, 2007 7:21 am

I found a quick way for it to fail:

Wizard Joined: 14 Aug 2004 Posts: 1269

And does the trigger indeed not compile?

Posted: Sun Oct 21, 2007 6:15 pm

That example doesn't, because $t is an invalid local variable, but other examples that perhaps should work don't.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I haven't checked it but this should work correctly. If it does not then perhaps Zugg can suggest something that will, or a parser change is needed.
#LOOP 5 {#ECHO ${t%i}}

Posted: Mon Oct 22, 2007 8:02 pm

Nope that variant doesn't work either.

Error compiling script:
invalid local variable: t%i

Posted: Mon Oct 22, 2007 8:08 pm

Sorry, this is just a bug. Local variables were changed to return a numeric reference so that commands like #ADDITEM could work with this. But this has had a nasty side effect of always returning a numeric value instead of the local variable contents in all sorts of other scripts. So yes, local variables are a bit broken right now.

In the case of the command:

#LOOP 5 {#ECHO ${t%1}}

you *cannot* perform any indirect local variable lookups. I think you *might* be able to use the %param function to look up named arguments, but I don't think it will work with local variables. Local variables are stored on the runtime stack and are not available to any of the "implicit concat" kinds of parsing syntax. Anything that requires *runtime* parsing vs *compiled* parsing will not work with local variables (because they are only available at compile time).

So, there is no way to product a local variable reference that is evaluated delayed at runtime. Local variables can only be direct references, which is why they are so fast.

Posted: Mon Oct 22, 2007 8:21 pm

Shouldnt an explicit concat work though? cause %concat( "$t", %i) doesnt work either.

Posted: Mon Oct 22, 2007 8:25 pm

No. Because %concat("$t",%i) is creating the name of the local variable at *runtime*, and local variable names are only available at *compile* time. The compiler converts all local variable references into indexed locations on the runtime stack. At runtime these local variable names no longer exist.

When you use a local variable like $t1 in your script, look at the compiled code tab in the settings editor. You'll see that this was compiled as "Localvar 1" or something like that. In other words, the name "t1" is gone and is replaced by just a number. So at runtime, there aren't any names left so when trying to create a name at runtime like with %concat, there is no way to convert this into a numeric index anymore. Again, that's why local variables are fast...because they are converted to numeric indexes at compile time and not at runtime.