Forums Feature Suggestions Advanced If's

I was using if's earlier today, and it dawned on me that MSL doesnt support advanced if's..

an example would be an OR comparisson on $3

if ($3 != (YES || NO)) { ... }

Currently you have to specify them individually..

if ($3 != YES) || ($3 != NO) { ... }

Advanced if's would be nice

Seconded.


*edit*

I might append to this. (Keeping in theme with the whole "if" thing.)

In a few programming languages <> usually means !=, like in Visual Basic:



So would it be a bad idea to support <> as != also?

I thought <> meant == but only for numerical values (integers)

since logically, <> would be not higher or lower than, which would mean equal to, since its the only true in the statement...

I always thought <> meant not equal to ...

ahh, thats true, since <> would be if it IS higher or lower than (meaning not the same) but again, this would only be for numeical values...

i guess you could have !< and !> and in turn, !<>..

then you could go mad and have <!> if lower or not higher, which would be the same as <=

please let us not look to vb for inspiration.

I second (a || b)

another cool thing would be to be able to assign var using the || operator.

var %a = %b || %c

and while were on subject of if adjustments

if (%a = %b) {
;%a now holds %b
}

Doubt it will be added though since its not a minor adjustment nor would it be very backward compatible :p One can dream..

yes, yes and yes..

I love the variable idea, and variable assignements in the if

if (%a = %b) {

assuming if %b is set, (and in turn %a) then its 'true' and activates, if %b = $null, (and in turn %a isnt set) then its 'false'

that would be nice...

Eck, I'd hate to see side-effect assignment in mIRC scripting. It's shady enough in other programming languages, in a supposedly "newb-friendly" language like mIRC's it'd only cause trouble and abuse. It's also redundant since in 99% of cases you can use $v1 instead.


Reply to Jigsy:
I don't see why supporting two ways to do exactly the same thing would be beneficial. As this thread has already shown, <> is not nearly as clear in its function as != and in the few languages besides BASIC in which it is supported it's usually considered deprecated or obsolete.

I'd have to agree with starbucks. No need to allow <>. Why add something that does exactly the same thing as something we already have and doesn't even save any space (i.e. same number of characters to do it)?

As far as allowing "advanced" if statements... I see that as a way to run into confusing scripts. Yes, you'd know what you meant, but someone who isn't a good scripter or isn't very good at logic would find it confusing. Right now, you can easily see what is being compared. With that, it isn't so clear to see for someone without the scripting/logic background. And I really don't see any improvement by having that as an option. It just saves you a little typing.

but there's various things that there are 2 methods, depending on scripting style/preference

such as, for example you can use 2 methods for variables..

var %this = that
%this = that

to me, thats the same as the if statements, more than 1 way, confusing for scripters (that tripped me up at the start)

and to me, knowing || = or..

if ($3 == (This || That)) is much less confusing than
if ($3 == This) || ($3 == That) - its also much easier to debug...

then you go into making it look even more complicated again, due to scripting style..

if (($3 == This) || ($3 == That)) -- again, this works, its perfectly acceptible, but more brackets, and ends up looking even more confusing..

I agree.

if ($3 == this || that) - if $3 equals this or that
vs.
if ($3 == this || $3 == that) - if $3 equals this or $3 equals that.

It just seems like a very longwinded way of saying the same thing..

var and the %varname = value syntax do not do the same thing. var declares variables as local and allows multiple variables to be created at once. %varname = value can only assign one variable and uses the same scoping rules as set (ie. the variable will be global unless previously declared as local by var). %varname = value is also faster than var (presumably at least in part because of having less capabilities).

Well I previously wasn't particularly against the more complex expressions suggestion (besides the side-effect assignment), but now I'm not so sure it's a good idea. Your post demonstrates a common misconception in what's happening in that expression that I think would only serve to confuse a lot of scripters.

if ($3 == this || that)
is not the same as:
if ($3 == this || $3 == that)

if ($3 == this || that)
is actually saying:
if ($3 == this) || (that)

Even if you made it
if ($3 == (this || that))
it would still not be checking what you think, it would be checking that this or that were $true (or any other non-$false/$null value), and then checking the result of that sub-expression is equal to $3

So if this was actually a variable that had a value of 0, and that was actually a variable that had a value of 0 then the subexpression would be $false and the larger expression would check if $3 was $false. If either of the this or that variables had a non-$false/$null value then the sub-expression would be $true and the larger expression would check if $3 equals $true.

In short, I think a lot of people would make the mistake you did. Also, realistically mIRC would probably have to support operator precedence to make complex expressions really useful without needing dozens of parentheses all over the place. I doubt it'll happen, and I'm worried it'd end up doing more harm than good if it ever did.

True, I noticed that after I posted. Could always add a new operator..

the end results are the same

if ($3 == this) || ($3 == that)
means, if $3 is this, or if $3 is that

if ($3 == (this || that))
means, if $3 is this, or that

its compressing 2 'virtual' if's (since the second, in the first example is a 'virtual if') into the single if, it would however, give the same outcome.

At that point what you really want is a list structure instead (which is something I definitely would like to see, but that's way offtopic for this thread). Then you would have something like

which is far more powerful and useful in the long-run (not to mention all the other benefits of lists).

Of course at present the common way for handling these situations is to use

which is limited but still effective for most tasks. And still more readable IMO than trying to make an operator do it.

They're not the same. Read my response to hixxy's first post to explain what would actually be checked by that condition.

ok, the example im wanting..

in a script $2 = the command and $3 = sub command..

its NOTI on/off

I have
if ($2 == NOTI) {
if (!3) { msg $nick you need to specify }
elseif ($3 != ON) || ($3 != OFF) { msg $nick you should specify ONLY on or off }
else { ... }
}

so, in the above example, it would read as..

if ($2 == NOTI) {
if (!3) { msg $nick you need to specify }
elseif ($3 != (ON || OFF)) { msg $nick you should specify ONLY on or off }
else { ... }
}

Meaning if $3 isnt either on, or off...

A list structure would be handy indeed (like an array?)

I've used two different ways to implement them so far, one is to use a hashtable but name your items in an incrementing order. This is allows you to loop with $hget(table,N) rather than $hget(table,N).item, ..so they're actually sorted.

And the second is to use a binary variable, and separate the items by a null character, seeing as it's the only thing you're never going to find in text.

Both of these are quite slow though and no doubt a lot more sloppy than if it was supported natively.

I understand what you want it to do, I'm just explaining that's not how it would work. That's just not what the || operator does.

You would need an entirely new operator for that, something that basically created an implicit list. But in that case it's better not to use an operator at all, instead it would make more sense to have mIRC support lists in general (in the same way it supports hash tables) and then to use an identifier to check if x is contained in that list.

Or, as I explained in my response to hixxy's second post, you can use the existing method of tokens and $istok().