mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2006
Posts: 546
J
jaytea Offline OP
Fjord artisan
OP Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
hi there,

a few of us have been investigating the evaluation routine employed by if (and by extension, while) statements and have come to the conclusion that although the current behavior is all quite logical, there's still one minor amendment that would be very nice to see. i'm referring to, of course, evaluation brackets given higher priority in if conditions. currently the order of evaluation seems to be as follows:

complete if statement parsing including separation of conditions and separation inside conditions (v1/op/v2) -> normal code parsing (evaluation brackets followed by normal code evaluation)

what i propose is some 'splitting up' of these main two stages, and a re-arrangement of the order (or rather, an additional layer of earlier evaluation bracket parsing) :

if statement parsing only as far as separating conditions -> superficial evaluation bracket parsing -> condition parsing (v1/op/v2 establishment) -> normal code parsing

this would be very useful in cases such as this:

Code:
//var %a = 1 > 2 | if ( [ %a ] ) { ; code } 


which currently succeeds with $v1 = "1 > 2". now, most scripters with a reasonable understanding of evaluation brackets might consider this a bug at first glance. but looking at it deeper, the reason is quite clear and is summarized by the flow of parsing seen in my earlier conjecture. perhaps this didn't occur to the author originally, or since it requires the "splitting up" of those two distinctive operations it might be infeasible for some reason or another?

let me draw up some examples of what i'd like to see happen:

Code:
//var %a = 1 > 2 | if ( [ %a ] ) { ; code } 


false, since %a is evaluated early and the condition becomes "1 > 2" with $v1 = "1"

Code:
//var %a = 1 > 2 | if ([ %a ]) { ; code }


true, same as now. those evaluation brackets aren't considered at the extra early layer of evaluation i mentioned (since they're unspaced), only the last level. so $v1 = "1 > 2"

Code:
//var %a = $!a | if ( [ %a ] ) { ; code }


now, you might think this gets out of hand. if what i suggested were used, the if condition tested is <value of $a> and not <value of %a> as is the current behavior. while this might seem undesirable, i argue that the same thing happens right now in identifiers, with eg.:

Code:
//var %a = $!me | echo -a $+( [ %a ] )


therefore i don't see this as an issue. a final example:

Code:
//var %a = $!a < [[ $!b ]] | if ( [ %a ] ) { ; code }


yes, $b should be evaluated before $a, much like how $( [ %a ] ) would behave. incidentally, i find it impressive how Khaled thought of concurrently evaluating v1/op/v2, ie. if ( $a < [ $b ] ) evaluates '$b' first. it's as expected, but knowing that v1/op/v2 distinction is made before any evaluation occurs makes this a very interesting observation! you'd expect v1 -> op -> v2 to be evaluated one at a time, in order, at least i would :P

so evaluation brackets still have some degree of control in if statements, and i think they should have more. i suppose what i'm getting at here is having if/while behave more like identifiers to some degree, where evaluation brackets can be used to manipulate syntax (think the ol' $rgb() and a string with commas) but not vital syntax like () && || {} etc. this establishment should be done early, meaning the new layer of evaluation i propose wouldn't have major side effects

anyway, i'm rambling. this may appear to be more of a suggestion than a bug report (i seem to do this a lot lol) but at the same time, the average scripter would expect if ( [ %a ] ) to be treated differently than if (%a) and given the description of evaluation brackets that exists in the help file, they would certainly look at this as more of a bug than i do

wow, i typed a lot more than i was meaning to about that :S and i have yet to start whining about $calc()! i'll try to be brief, we all have probably come across $calc()'s 'special' evaluation routine at some point. the logical reason for it is, i assume, the necessity to correctly evaluate $calc(1+%var), $calc(2 * ($1 + 3)) etc. since those normally wouldn't evaluate properly in other identifiers. let's start with how it handles evaluation brackets:

Code:
//echo -a $calc(1 + [[ 1 ]] ) or $calc(1 + [ 1 ])


what appears to be happening is that $calc() has an entirely unique evaluation routine, a simpler one than what we've come to expect, but one designed to only honor variables/identifiers that touch mathematical operators and (, as well as those that succeed spaces and precede ). it overlooks evaluation brackets, possibly treating them as plaintext. but this leads to another shortcoming:

Code:
//echo -a $calc(1 $+ 1) $calc(1+ $+ 1)  


which you'd expect to return 11 2. yes this can be worked around somewhat by passing the input through an identifier such as $() first, $calc($(expression)). but that probably has some shortcomings related to passing through /scon, /scid, timers, and possibly more complex situations that i don't want to think of at this moment ;P

the first solution that comes to mind is applying the normal evaluation procedure for identifiers first, then this custom one to handle the variables/identifiers touching () and operators. but the flaw here is potentially dangerous double evaluations. i think this requires fixing, although i can't really suggest a simple fix. would be interesting to hear everyone's views on this! sorry for rambling ;D


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Joined: Jan 2004
Posts: 509
L
Fjord artisan
Offline
Fjord artisan
L
Joined: Jan 2004
Posts: 509
Originally Posted By: jaytea
would be interesting to hear everyone's views on this!

Yes, I suppose that too could be interesting to hear.

But be careful, you're dangerously using the word "everyone's." Your usage of that word could be evaluated badly. ;\

Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031

Originally Posted By: LostShadow

But be careful, you're dangerously using the word "everyone's." Your usage of that word could be evaluated badly. ;\


Your own reply proved that.

Joined: Jan 2008
Posts: 8
K
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
K
Joined: Jan 2008
Posts: 8
what a silly comments.

but to the point it is a bit weird, but is it worth the effort to fix something like this?


Link Copied to Clipboard