Error with evaluation brackets - mIRC Discussion Forums

Code

[ %var ] == $eval(%var,1)
[ [ %var ] ] == $eval(%var,2)

how come no brackets isn't $eval(%var,0) ??

it should be changed so that:

Code

var %x test
var %x [ %x ] $+ .please 
echo -a [ %x ]

echo's: test.please

and

Code

var %x test
var %x %x $+ .please
echo -a [ %x ]

echo's: %x.please

and

Code

var %test.please this is a test
var %x test
var %x %x $+ .please
echo -a [ [ %x ] ]

echo's: this is a test

Code

var %x %sometest
var [ %x ] this is a test
echo -a [ %sometest ]
echo -a [ [ %x ] ]

echo's: this is a test

you would need to use a special character to do $+ ie the ~ or some unused character

You're not going to have the language redefined after all these years. Depending on what you want to do, there may be some other constructs which achieve what you want.

//echo -a $eval($1,0) and $ $+ 1 and $!1

//var -sp %var abc $+ $chr(32) | var -s %a $gettok(sha1 sha256,$r(1,1),32) | echo -a $qt(%var) -> $($+($,%a,$chr(40),$eval(%var,0),$chr(44),0,$chr(41)),2) and $sha1(abc $+ $chr(32)) and $sha1(%var)

my question is how come [ %var ] doesn't yeild $eval($eval(%var,0),1)

on the tutorial at http://www.xise.nl/mirc/wiki/doku.php?id=eval

Code

[ A $+ B $+ C ] <=> [ [ A $+ B ] $+ C ] <=> $eval($eval($eval($eval(A,1) $+ $eval(B,0),2),1) $+ $eval(C,0),2)

which should be:

Code

[ A $+ B $+ C ] <=> [ [ A $+ B ] $+ C ] <=> $eval($eval($eval(A,0) $+ $eval(B,0),1) $+ $eval(C,0),1)

and

Code

[ $ev(b) [ $ev(c) [ $ev(d) ] ] ]

should be

Code

$eval($eval($ev(b),0) $eval($eval($ev(c),0) $eval($eval($ev(d), 0),1),1),1)

but the latter might be attempting to do the following

Code

[ [ $ev(b) ] [ [ $ev(c) ] [ [ $ev(d) ] ] ] ]

which is

Code

$eval($eval($eval($ev(b),0),1) $eval($eval($eval($ev(c),0),1) $eval($eval($eval($ev(d),0),1),1),1),1)

The explanation are correct, what do you mean by 'should' be?

element on a line are evaluated once in normal time. [ ] are not a way to evaluate some extra times, they only do it by side effect, [ ] change the order of the evaluation on the line, one [ ] means evaluates one time, same as without [ ]

ultimately if the default evaluator for identifiers is 1, then

Code

[ $1 ]

should be the equivelent of

Code

$eval($eval($1,1),1)

The [ ] brackets and the $eval() identifier are not related and share no common code. The [ ] brackets were added very early on in the scripting language's development to solve a specific purpose. They use their own parsing code that is separate from the rest of the scripting language that continued to evolve around them. As with all scripting features that have been in place for a long time, their behaviour cannot be changed, as that could break backward compatibility.

Originally Posted by Khaled

The [ ] brackets and the $eval() identifier are not related and share no common code. The [ ] brackets were added very early on in the scripting language's development to solve a specific purpose. They use their own parsing code that is separate from the rest of the scripting language that continued to evolve around them. As with all scripting features that have been in place for a long time, their behaviour cannot be changed, as that could break backward compatibility.

i think it could be a good feature; anyone who doesn't want to modify their scripts can use an older version of mIRC!

Originally Posted by Imk0tter

you would need to use a special character to do $+ ie the ~ or some unused character

instead of using a special character you could put the $+ in evaluation brackets

IE:

Code

[ [ A $+ B ] $+ C ]

becomes

Code

[ [ A [ $+ ] B ] [ $+ ] C ]

I still don't understand what the "feature" is. Can you specifically explain what the current version cannot do in relation to brackets? Other than the one I mentioned in channel where [ bracket ] strips spaces the same way the /tokenize 32 command would, so you'd need to switch over to something like $!1 or $eval() in order to preserve them.

Originally Posted by maroon

I still don't understand what the "feature" is. Can you specifically explain what the current version cannot do in relation to brackets? Other than the one I mentioned in channel where [ bracket ] strips spaces the same way the /tokenize 32 command would, so you'd need to switch over to something like $!1 or $eval() in order to preserve them.

i would call the feature 'proper evaluation'. with a default evaluator of 1 this code works

Code

% $+ %var

but ultimately with a default evaluator of zero this would be the code

Code

% [ $+ ] [ %var ]

to get the value of that variable you would use (for a default evaluator of 1)

Code

[ % $+ %var ]

but with an evaluator of 0 it would be

Code

[ % [ $+ ] [ %var ] ]

i can't figure out how to do this with the way the current bracket evaluator works!

EDIT:

apparently it's

Code

% [ $+ [ %var ] ]

but this is unintuitive and doesn't make much sense!

Quote

EDIT:

apparently it's

Code

% [ $+ [ %var ] ]

but this is unintuitive and doesn't make much sense!

this (in my world) breaks down to (with an evaluator of 0):

Code

[ % [ $+ [ %var ] ] ]

but is more properly written as

Code

[ % [ $+ ] [ %var ] ]

(i'm not quite sure what)

Code

[ $+ this is some text ]

evaluates to

Originally Posted by Khaled

The [ ] brackets and the $eval() identifier are not related and share no common code. The [ ] brackets were added very early on in the scripting language's development to solve a specific purpose. They use their own parsing code that is separate from the rest of the scripting language that continued to evolve around them. As with all scripting features that have been in place for a long time, their behaviour cannot be changed, as that could break backward compatibility.

what's the point of $eval when you have [ ] brackets?

to eval dynamically you can

Code

var %x 4,%y $!1
while %x {
%y = [ %y ]
dec %x
}

or even make your own eval function

Quote

what's the point of $eval when you have [ ] brackets?

The [ ] brackets were added when the scripting language was still in its infancy. $eval() was added later on as a method that was more in line with how the rest of the scripting language was evolving. This is what happens when you develop an application over a 25 year period while trying to maintain backward compatibility. It is your choice to use whichever one you find more useful in any particular situation.

Thanks for your comments everyone. This thread is now closed.