Few simple cases I tried..

I am a % (halfop) on #help... so most of these should have evaluated as false.. but they seem to give me true.. These were all done in #help itself (obviously) after I'd noticed a script misbehaving when I'd previously had #help exluded from the event.



What I had originally was (2) because that's readable proper syntax, now I'm stuck using (1) and it's annoying me greatly. This also means well over 50% of my other scripts (and there's a damn good many of them) will no longer function properly.

Please fire your beta testers, or at least have real programmers test these things in the future I don't see why this should have been missed. It is simple binary logic with priorities.

2) //if ((($me ishop $chan) || ($me isop $chan)) && ($chan != #help)) echo true
-2) any proper programmer knows it should be false

^^ that should return true IF you are op or halfop and the channel is NOT #help O_o whats the deal Sugi?

Yes there appears to be an issue with certain compound conditions.

Of course as a real programmer I'm sure you're well aware that mIRC's parser doesn't support operator precedence at all and therefore the additional grouping parentheses are redundant in every case shown.

symphony::
That's the whole problem, it shouldn't return true if the channel IS #help, when that segment of the if statement is false, so in otherwords..

if $true && $false = true..

so 1+0 = 1

From the truth tables of binary logic:

0+0 = 0
0+1 = 0
1+0 = 0
1+1 = 1

This is not happening anymore.

1) Yeh, and there was no problem with the compound conditions before 6.33, hence the error report.
2) I use the extra parenthesis to give my code clarity and readability, rather than the disgusting forms some people use that are:

if con1 || cont || con3 doing stuff

Which can get people lost if you start placing multiple if's on a line, or the doing stuff and condn look similar, etc etc... you get the idea. Either way I see that poor ethics in code a ton because mIRC allows it for some godforsaken reason. I know mIRC isn't something to be used in a real programming project; but it's still usable as a foundation for users to learn how to work with a simple language and mostly well documented coding language. Just would make more sense if it also enforced at least some proper coding practices such as enclosing your entire if conditionals in parens.

3) Mirc actually does give operator priorities correctly, but it seems to lose that once parens are invovled when it didn't used to have this problem. If you test the following two lines, which should be completely different.. they are as such.

if ($true || $false) && $false return $true
if $true || $false && $false return $true

The first will give the OR's priority since they're grouped, and then add in the AND. This allows for a false overall statement and so true is not returned.
The second one will perform the AND first, get a $false out of it resulting in "$true || $false" which is still true and thus means the operator priority is still maintained. As such $true is now returned.

When the entire line is grouped is when the funny things start to happen, and that is what I demonstrated in my first posting.
So to put it in these same terms now that you've seen how it works ungrouped..

if (($true || $false) && $false) return $true

Will happily sit by and return $true, despite the statement being false as the ungrouped version specified correctly. This means that somewhere along the parsing of the additional parens, which actually would not change any of the priorities and simply acts as an encapsulator of the entire if line, the internal paren parsing is gone and no longer applies (as I demonstarted in (3) above with the excessive parens.


Hope that makes it clearer!

No, it doesn't. That was was my point. mIRC does not have any operator precedence rules, it merely chains from left to right. will be false in mIRC.

I can confirm this, i got the same problems with mIRC 6.33 in several Scripts (6.32 works fine)

Putting it another way, in 6.32 neither of these return true:

//if ( ( $true || $false ) && ( $false) ) echo -s returns true
//if ( ( $false || $true ) && ( $false) ) echo -s returns true

however in 6.33 the first one incorrectly returns true

Thanks, I have decided to revert the change to the if/while bracket parsing routine back to the method used in v6.32. I plan to release a priority update for this issue soon.

The current beta-testers are doing a great job - they catch a large number of issues before a release is made. Beta-testers have to deal with a whole range of issues and changes, many of which can be very time-consuming to test. Sometimes subtle changes are made repeatedly to a feature, like this one, which need to be tested again and again. Multiply that across the fifty or so changes that were made in this release and it's not an easy process, and sometimes issues can be missed. That is simply the nature of the testing process I'm afraid.

All right, thanks a ton Khaled, keep up the good work!!!

Hi folks,
I've been holding off on going to 6.33 because of that bracket parsing problem which totally breaks all of my scripts. I know it's probably futile to ask when the next release is coming but I am anxious to get the latest version and not have it break my scripts. Any estimate on when the fix will come?
Thanks

Look at the post of Khaled in this thread :
But be aware of the date won't change anything

Assuming the above is true and has always been true...

Is there any chance that using parentises (sp) will be added anytime?

So that something like ($True && $False) || $True will always return true? I'm been using parentises for a long long time and never new that mirc didn't process them like that. Its a wonder my scripts work at all at this point.

Given that the latest change completely backfired, I doubt Khaled will be playing with the conditional parser again any time soon.

What you've posted will always return true as you expected. mIRC respects parentheses for grouping (at least once the 6.33 bug is fixed), my point was merely that it doesn't have operator precedence - eg. in the absence of parentheses mIRC will not give && higher precedence over || as would occur in most other programming languages.

Ah, I'm sorry. I misunderstood what was going on.

Thanks.

This may be a little irrelevant, but just for the record, the "+" sign is used for logical disjunction (OR), not for logical conjunction (AND). For "AND", you should use either "&", "^" (which should really be an inverted "v") or a middle dot:


0^0 = 0
0^1 = 0
1^0 = 0
1^1 = 1