Forums Bug Reports bugs with variable setting

these might be old but at least one of them is quite important, so i've decided to repost them with some detail :P

1. not possible to set variables with a single trailing space, ie.



this one's quite important, imo, a lot of people write loops that iterate through a string, adding characters onto the end of a variable. as a result, they end up with lost spaces. sure the fix is usually simple, but it would be great if it worked both ways :P

this also comes into play when setting any arbitrary text, such as user input, to a variable.. so it's one that i come across a lot

2. /var with identifiers as variable names, eg.



not only does this fail, but nothing appears to be evaluating (in value at least), and no errors are thrown. i suspect it must be hectic to parse these things, especially given /var's capability to set multiple variables, but since /set supports names of this nature you'd expect /var to by extension

3. there's no way to fill a variable with "". not even via:



i appreciate that some people might use %var = "" to empty a variable, a convention taken from some other languages perhaps, but to not be able to fill a variable with 2 quotes AT ALL just seems a bit unreasonable :p

i propose that at least /set -n accomodate this change, certainly $regsub, but maybe not /var or /set (or its alias, %var =) for backwards compatibility

Comment on 2.:

I don't think it follows that /var should have /set's behaviour. One of the reasons they are different commands is because they have different behaviour--

More importantly, it would be pretty impossible to parse $() in var-- the following example expects the output: "the answer is, %x = 5" ($ans returns "%x")



Should that set %x to 5, or did I mean the above expected output? The grammar is far too ambiguous to tell, which is why the prefix % is necessary in var to remove such ambiguity. This is both a parser problem and a programmer's concern, especially if the programmer in question expected the above output (as 6.31 handles it).

The behaviour in /set does not allow multiple variables so this does not become a problem and it can happily accept $ as the prefix-- but the behaviour of var is different enough to justify this restriction.

There are potential issues with #3, as "" are considered $null during evaluation. For example, if you open the Variables section and add %a "" there, //echo -a $len(%a) echoes 0, not 2. There is a way to see what %a really contains ($var(%a,1).value), but such an inconsistency could still cause problems with scripts that handle dynamic input, not to mention that the scripter should be constantly aware of this and take appropriate measures (something that will almost certainly not always happen).

This could be solved in local vars, but in global vars it would require storing additional persistent information (which wouldn't be practical and would come with other issues).

hi!

well argv, after reconsideration i'm going to conclude that you're right, but for the wrong reasons ;P in your example, i would have said yes.. $ans should be checked for being a potential variable name. i would have reasoned that the , is strictly part of /var syntax just as commas are also a part of identifier syntax, and should be treated as such. if the scripter didn't want to indicate a new variable declaration they could just as easily escape it with something like $chr() as usual

i can't actually think of any examples in which the outcome would be non-deterministic, but the mere fact that the decision making can get quite confusing, more so when considering the =, makes me second guess the suggestion (in retrospect, i guess it was more of a suggestion than a bug report ;P)

a better example of potential confusion would be here:



so, what should happen if i had my way? mirc would see the , and then try to figure out if the next piece of code was a variable name. it would have to evaluate $+(), but which value should it use for %a? if it is indeed a new variable declaration, then it should use the value of %a that was just declared, "%x", and as such it would consider it a new declaration. i'm thinking it should 'try' the new value of %a, if the result turns out to be a variable name.. go with it. if not, then reverse your steps to the comma, re-evaluate it the way it does now

even in that case though, the result would be completely deterministic. but the series of rules i described above might just be too obscure to be considered

qwerty, i hadn't realized "" was also treated as $null during evaluation as well as assignment, that's just plain wrong :P i mean, if the scripter managed to assign "" to a variable, as you said it could only have been done explicitly through the scripts editor. for mirc to not honor that is quite inconsiderate indeed!

i'm not sure what you mean by storing additional information, the logical fix here is to adapt the assignment side of things slightly: give only /set -n the ability to store "". but the evaluation side of things should be changed completely, "" should not be evaluated as $null at all, since if it exists in a variable then it had to have been put there with great intent

Another related /var (and /set) thing is that you can't set a value that is a basic operation like //Var -s %a 1 + 2.