Semiconductor & Computer Engineering
m |
(→Solving the space issue using $+()) |
||
| Line 187: | Line 187: | ||
== Solving the space issue using $+() == | == Solving the space issue using $+() == | ||
| − | By | + | By now we already know that the following code will only evaluated once since it violates the first rule: spaces in the code segment. |
<source lang="mIRC">//echo -a [ [ a $!me ] ]</source> | <source lang="mIRC">//echo -a [ [ a $!me ] ]</source> | ||
Revision as of 20:53, 19 December 2014
Normal code is executed, as you are probably aware, top down and left right. Evaluation brackets are a mechanism by which a program can alter the natural behavior of the mIRC interpreter.
Evaluation brackets allows us to:
- Change the order of evaluation
- Change the number of evaluations
Contents
Order of Evaluation
Consider the following code:
//echo -a Hello World, it's $me $+ !
A typical code is evaluated from left to right, one word at a time.
alias x echo -a $1 | return $1 alias eval_example { echo -a $x(1) $x(2) $x(3) $x(4) }
If we run the code above we will get the following result:
1 2 3 4 1 2 3 4
As expected, $x(1) was evaluated first, $x(2) was evaluated second, $x(3) was evaluated third and $x(4) was evaluated last. Earlier we said that we can use evaluation brackets to change the order of evaluation. We will demonstrate that in our next example:
alias x echo -a $1 | return $1 alias eval_example { echo -a $x(1) [ $x(2) ] $x(3) $x(4) }
In this example we surrounded $x(2) with a pair of bracket. The code produced the following result:
2 1 3 4 1 2 3 4
From the output you can see that $x(2) was evaluated first (as shown in the graph below). Once the content of the evaluation bracket was evaluated, the parser went on to evaluating the rest of the line like it would normally from left to right.
Note: Changing the order of evaluation does not change the position of the evaluated value in the actual line.
We can have multiple groups of brackets on the same line. Note that once the parser is done evaluating the first block (from left to right), the parser will proceed to the next pair of evaluation brackets. Let's look at the following example:
alias x echo -a $1 | return $1 alias eval_example { echo -a $x(1) [ $x(2) ] $x(3) [ $x(4) ] }
The code above produced the following results:
2 4 1 3 1 2 3 4
This time we have two pairs of evaluation brackets. mIRC went from left to right evaluating $x(2) first then $x(4). The parser then went on to evaluate rest of the line.
Nested evaluation brackets
Once the parser reached the first evaluation group, it enters it. The process begins all over again inside the evaluation group - it evaluates the content from left to right. If we nest another pair of evaluation brackets we force the parser to evaluate that part first then continue on to the rest of the evaluation content inside that bracket.
Consider the following code:
alias a echo -a A alias b echo -a B alias c echo -a C alias eval_example { noop $a [ $b [ $c ] ] }
The code above produces the following result:
C B A
The graph above demonstrates how once the parser enters the outer pair of brackets, the entire process starts all over and the first thing that gets evaluated are the inner brackets.
Note: once an evaluation group is complete, it is take out of the rest of the line.
Interestingly enough, with three identifiers it is possible to generate every single permutation by just using evaluation brackets:
alias a set %str %str $+ A alias b set %str %str $+ B alias c set %str %str $+ C alias d unset %str alias eval_example { echo -a ABC => $a $b $c %str $d echo -a ACB => [ $a ] $b [ $c ] %str $d echo -a BAC => $a [ $b ] $c %str $d echo -a BCA => $a [ $b ] [ $c ] %str $d echo -a CAB => $a $b [ $c ] %str $d echo -a CBA => $a [ $b [ $c ] ] %str $d }
Will produce the following result:
ABC => ABC ACB => ACB BAC => BAC BCA => BCA CAB => CAB CBA => CBA
Number of Evaluations
Until now we have been dealing with the order by which the interpreter evaluates things. We will now move on to looking at how many times a single evaluation block gets evaluated.
Under normal conditions, every part of the line is evaluated exactly once.
For simplicity sake we will define a normal condition as any statement that does not contain $(), $eval(), or $evalnext(). The statement above should feel pretty intuitive. Consider:
//echo -a [ $!me ] [ $!me ]
The above code is logically equivalent to:
//echo -a $!me $!me
In both cases everything is evaluated once. A single pair of evaluation brackets causes the interpreter to evaluate the code once.
A code segment is evaluated once more for every additional pair of enclosing evaluation brackets unless:
1. The code segment contains spaces, and
2. It does not contain $+ to "close the space gap"
If the conditions above are violated, the code segment is evaluated only once. Any additional enclosing evaluation brackets are simply ignored.
We will talk about the $+ case later on.
Spaces in code segment
A space in the code segment is a violation of the first part. This nullifies the behavior of the reset of the enclosing brackets. Here is an example:
alias exe echo -a I was called! ; example: alias example echo -a [ [ [ [ [ [ [ [ [ [ [ [ [ Hi! [ $!exe ] ] ] ] ] ] ] ] ] ] ] ] ] ]
The code above will indeed print:
Hi! $exe
Note: The exe alias was never called, not even once. Before we move on, it is important to note that if we have a code segment inside another code segment. That code segment follows the rules all over from the start. Consider the following example:
//echo -a [ [ [ a $!me ] ] ] <=> [ [ [ a [ $!me ] ] ] ] <=> [ [ [ a [ [ $!me ] ] ] ] ]
The last part had a sub-code segment with no spaces: "[ [ $!me ] ]". Since $!me has no spaces, it will be evaluated once (to $me) and then the outer brackets will evaluate it once again to your name. In my case we get "a David". Since now we have a space in the code segment, all the outer brackets are nullified (as with the other two cases separated by <=>).
The code above will produce something like:
a $me <=> a $me <=> a David
Multiple evaluations
If we follow the simple rule above, we can easily evaluate a specific code segment multiple files. Consider the following example:
alias exe echo -a I was called! | return Hi! ; example: alias example echo -a [ [ [ [ [ $!!!!exe ] ] ] ] ]
The above code prints:
I was called! Hi!
Here is a more interesting example of multiple evaluations:
alias a return $!b alias b return $!c alias c return $!d alias d return Surprise! alias example echo -a [ [ [ [ $a ] ] ] ]
The above code will print:
Surprise!
Solving the space issue using $+()
By now we already know that the following code will only evaluated once since it violates the first rule: spaces in the code segment.
//echo -a [ [ a $!me ] ]
Prints:
a $me
The easiest way to fix this issue is to surround the entire group with $+() and put a space ($chr(32)) between the two tokens. This means we no longer have spaces (note that spaces inside the identifier are superfluous).
//echo -a [ [ $+(a, $chr(32), $!me) ] ]
Because we now have no spaces, the additional evaluation bracket is not ignored and our code is evaluated once again:
a David
$+ Special behaviors
Inside evaluation brackets, the $+ concatenation bracket exhibit some special behavior.
[ A $+ B ] Format
The rule about [ A $+ B ] is:
The [ token_A $+ token_B ] arrangement will cause token_A to evaluate once and then be concatenated to token_B (evaluated zero times). I.e.: [ A $+ B ] <=> $($(A, 1) $+ $(B, 0), 2)
Additional pairs of $+ are treated in the same way as if they were grouped using evaluation brackets:
[ A $+ B $+ C ] <=> [ [ A $+ B ] $+ C ]
Which can be written as:
$($($($(A, 1) $+ $(B, 0), 2), 1) $+ $(C, 0) ,2)
This pattern can be extended to unlimited number of tokens.
Here is a quick example showing how the second token is never evaluated:
//echo -a [ x $+ $y ] and [ x $+ %y ]
Which prints:
x$y and x%y
Let's wrap this section with a strange line of code:
//var %x = % $+ y, %y%x = Works! | echo -a [ %x $+ %x ]
A [ $+ B ] Format
With the A [ $+ B ] Format, we have:
The token_A [ $+ token_B ] arrangement will cause token_A (evaluated zero times) to be concatenated to token_B (evaluated zero times) and then the concatenated string is evaluated. I.e.: A [ $+ B ] <=> $($(A, 0) $+ $(B, 0), 2)
Note that a $+ at the beginning of an evaluation bracket causes this zero-eval behavior to propagate to every other token in the group:
A [ $+ B $+ C $+ ... ] <=> $($(A, 0) $+ $(B, 0) $+ $(C, 0) $+ ..., 2)
Consider the following example. Before of the initial $+, all the other identifiers are never evaluated before being concatenated:
//echo -a X [ $+ $a $+ $b $+ $c $+ $d ]
As expected, we get:
X$a$b$c$d
Here is a better example
//var %x$a$b$c$d = Example! | echo -a %x [ $+ $a $+ $b $+ $c $+ $d ]
The code above prints:
Example!
Note that other, unrelated, tokens are still evaluated as we expect:
//echo -a X [ $+ $a $+ $b $+ $c $me ]
As expected, we get:
X$a$b$c David
A [ $+ [ B ] ] Format
The A [ $+ B ] format is not very helpful alone since B is never evaluated. We can combine our ability to evaluate things multiple times with the A [ $+ B ] format to form some more usable things.
A [ $+ [ B ] ] <=> $($(A, 0) $+ $(B, 1), 2)
The most common application of this is dynamic variables. Consider the following segment:
//var %foo.6 = Works! | echo -a %foo. [ $+ [ $calc(2*3) ] ]
The most common form is %var. [ $+ [ $nick ] ] which allow you to retrieve a value from a variable specifically created for $nick.
Escaping Evaluation Brackets
Evaluation brackets can be escaped by using double brackets ([[) without spaces. For example:
//echo -a [[ [[ example! ]] ]]
The code above prints:
[ [ example! ] ]
Note that without a complete pair, a single bracket is not treated as anything special. The following example is also acceptable:
//echo -a [[ [[ example! ] ]
It's a good time to also note that escaped evaluation brackets are not exactly the same as using $chr(91) and $chr(93). The escaped evaluation brackets happen at the same phase of evaluation as the actual evaluation bracket processing. Consider the following example:
//echo -a $mid( [[ [[ example! ]] ]] , 1) => $mid( $chr(91) example! $chr(93) , 1)
The code above prints:
example! => [ example! ]
Special behavior inside identifiers
By now you know evaluation brackets happen before the code itself evaluates. It turns out that when an identifier evaluates, it will correctly parse code that is a direct result of the evaluation brackets. Here is some code to demonstrate this behavior:
//var -s %x = mid(@Example!,2,8, %y = ) | echo -a $ [ $+ [ %x $+ [ %y ] ] ]
The above code prints:
* Set %x to mid(@Example!,2,8 * Set %y to ) Example!
Here is another one:
//var %x = @@XYZ@@,3,3 | echo -a $mid( [ %x ] )
Which will print:
XYZ
The interpreter is able to handle the commas and braces as part of the code.
Additional Odd Behaviors
Below are a few odd behaviors that are worth mentioning.
[ A $+ ] B Format
The reason we have not mentioned this format above is because its behavior is rather buggy. The [ A $+ ] B format behaves like [ A $+ B ] where B is evaluated zero times. This behavior propagates to multiple tokens as well. For example:
//echo -a [ A $+ ] $me $+ $me $+ $me
Prints:
A$me$me$me
This is more of a buggy behavior than anything else and should be avoided. Any code that relies on this is almost certainly doing something wrong.
$++
This construct behaves just like the $+ construct without exhibiting the special behavior inside the evaluation brackets. Note that normally there is no reason to use this construct. Here is an example:
//echo -a [ $!!me $++ $!me ] vs. [ $!!me $+ $!me ]
The above code prints:
$!me$me vs. $me$!me
Commands with Special Behavior
Not all commands are equal. Below is a list of some regular commands that have special evaluation routines that allow us to get the job that would otherwise require evaluation brackets:
alias example { var %x $+ $calc(4 * 4) $+ y 200 inc %x $+ $calc(4 * 4) $+ y echo -a : %x [ $+ [ $calc(4*4) $+ y ] ] unset %x $+ $calc(4 * 4) $+ y echo -a : %x [ $+ [ $calc(4*4) $+ y ] ] }
The code above will print:
:201 :
Note that unlike the reset of the commands, /unset cannot set variables in the format of %var $+ %var. Evaluation brackets are needed to fix this. This is most likely a bug.