The following will work just fine


The following will not


(Should give 2 Unknown command)

It's understandable that the if may still be trying to compare the two %b's and whatnot, but they're essentially the same code, yet the %b is treated as a command.

If you do not use proper formatting you are bound to get errors like these...

//var %a = 1,%b = 2 | if (%a < %b) { %b = 3 } | echo -a %b

Sometimes proper formatting isn't enough. If one way works, the other should as well.

Straight from the mIRC help file (/help /if):


So, I wouldn't call this a bug.

Of course it's a bug. Either the first one is a bug, or the second one is. Because the literally same command does different things. I know it says that in the help file, but that doesn't mean it shouldn't be fixed.

If you think "echo -a %b" and "%b = 3" is the same command...

Why not just use proper formatting and forget about all these "problems"?
I rather have a few brackets more and have my script work all the time instead of having a 50/50 chance of it working...

Because if you've ever done a challenge to create the smallest code, you'd feel the same way.

Edit: And yes, they are both commands.

Well I still hope Khaled will fix the more important bugs rather than working on a guessing engine for people not willing to use brackets :P

Probably it's a bug that the variable assignment isn't recognised. However your reasoning for why you can't use a workaround is silly. Smallest code competitions are possibly the stupidest things ever. Nowhere in any other form of coding is making something small at the cost of extremely low readability considered to be a good thing. Perhaps with the exception of certain Perl zealots *pauses for jeers*.

Not entirely. Smallest code challenges are quite good in showing off your skills, that's why they're challenges in the first place. And it's a VERY good way to find lots of mIRC bugs and limitations. You'd be surprised how many bugs have been found through these little challenges.

I'll have to agree, at least the way these competitions have been done so far. I really don't see the point in making the code ugly as hell and testing the parser's tolerance just to save a few bytes. Many of the submissions in such competitions don't even work in the next version of mirc because they rely on quirks, undocumented things and behaviours prone to change.

That doesnt' mean that smallest code shouldn't be part of the competition at all. Between two scripts that work equally well (which means they're equally correct, fast and stable), most people would prefer the smaller one. But smallest code being the only objective is pointless. Fastest code competitions would be much more meaningful, for one.

-General reply-

Heh, I think challenges are there to be just a little bit of fun...IRC isn't all abuse, seriousness and politics you know. Sure it tests scripter's abilities, but it's not meant to be some form of the Olympic Games, nor is it meant to be a challenge to find out who can create the best script ever...just a bit of fun for people to do if they are bored. A lot of the time, people who script say they don't know what to work on for their next project - well, whilst their thinking, they can have a go at the challenge, or other activities that various websites provide.

If there is a bug in mIRC and someone takes the time to report it, then leave Khaled to take notice of it and fix it if feasible. If workarounds are suggested, then the person who reported the bug should be thankful to the person or people that provided that workaround and use it, or put up with whatever is causing them inconvenience for the time being.

Regards,

It`s not a bug, it`s a feature:

first i argge with you small code
but you script is buggy
the are two ways to make the code

way 1:
if (%x < 10) goto next

wav 2:
if %x < 10 { goto next }


1:
//var %a = 1,%b = 2 | if (%a < %b) %b = 3 | echo -a %b
2:
//var %a = 1,%b = 2 | if %a < %b { %b = 3 } | echo -a %b

also this is not a bug you jus used the if-then-else wrong

The ( ) brackets enclose comparisons, whereas the { } brackets enclose the commands you want to be performed if a comparison is true. You must make sure that the number of ( ) and { } brackets match to make sure that the correct comparisons are made, and that the correct commands are executed.

There's nothing wrong with the way I used my if-then-else statements. They're all valid.

zack if you are right next time dont use //var %a = 1, %b = 2
just use your way //var %a = 1 %b = 2

.....

Indeed. A fastest code competition in a langauge like mIRC's also has an implicit nod towards small, clean code since typically a critical element to obtaining performance is of course to reduce the number of operations and the amount of parsing without making code ambiguous.

I think taking a relatively simple task and asking people to make the fastest code gives people a far greater chance to utilise some skill and is also far more enjoyable and practical. A good example I think was the thread in the Scripting Forum a while back with the $reverse identifier where throughout the thread we went through about half a dozen different implementations and algorithms, getting faster each time until the final solution worked out many times faster than the code that you'd traditionally see used to reverse text.

Indeed, "fastest" challenges are good in themselves, but also don't work for all instances. And even fastest challenges will make the user go beyond what's the norm and try and make the code as efficient as possible, even breaking what I wanted in my first post. Such as doing while something { } instead of while (something) { } and various other ways.

In the end, challenges are there to be... well... challenging To test what your skills can and can't do. Smallest code challenges do this, and many people like seeing how a rather large problem can fit into a 100 byte code. Because there's a lot of nice tricks you can do with mIRC Scripting, and still, a lot of limitations.

I was simply asking for one bug/limitation that works in once case, work in the other. But it seems a group of people would rather go out of their way to flame what even many of the top scripters do themselves, challenges, especially smallest code ones.

Also, I didn't ask Khaled to put this as his number one priority, I couldn't really care less if it wasn't fixed for 6 versions. I was simply reporting a bug that I found which I thought this board was for

I didn't want this to start into some big debate about the requirement for specific challenges, I was simply stating what was in my first post. This is, after all, the bug reports board, and it is indeed a bug.

This is definitely not beyond the norm, as item #140 of v5.4 versions.txt explains.


It's a forum, discussions are made and threads get a bit off-topic all the time. This is not something you can (or should) control. We know that you simply reported a bug and we also know that if you don't want to be part of the "big debate", you can happily ignore the thread (which you could have done after your first post) Oh, and I'm sure nobody's intention is to flame (although starbucks_mafia's wording was a little bit too "sincere" :tongue:), we're just discussing about related mirc subjects.

The real issue is that I shouldn't have allowed the use of if-statements without () brackets in the first place.

The programming languages I've seen require the use of brackets in if-statements, and the reason is simple: without brackets, it is often difficult for the parser to know which values in an if-statement are part of the comparison. That's why it is important, as the help file states, to use () and {} in if-statements to make it clear what you are trying to do.

I have actually considered making the parser require the use of () (just like perl and C, and {} as well) in newer versions of mIRC but that would break all existing scripts.

I, for one, am glad that you aren't making () required. I've found that if you always use {}, ()'s aren't necessary, unless of course you want to specifically alter the order of evaluation of conditions. I've found (from the countless /if statements I've written till now) that with the usage of {} only, the parser works correctly in 100% of the cases.

I'd also like to see it be a requirement, but only as far as ()'s are concerned. I mean as you mentioned, all (or most) major languages require "parent" ()'s around a condition--why should mIRC be different? I know several who have started scripting in mIRC and moved on to PHP, C, C++, or even java and they notice the syntax demands them to use them.

I really don't want to start an argument, just putting in my 2 cents. IMO, I really don't think it'd be that harmful if you added the requirement. Most scripters with the skill and knowledge of making complex and sophisticated scripts (i.e. ones where losing backwards compatability could kill hours/days/weeks of work) already use 'proper' syntax. But then again, you have the others such as qwerty whom do not use them. I mean no offence meant, but ()'s are the way to go.

Perhaps more a reply to qwerty than to KT - most languages require the () around the conditional. C/C++ only requires the {} around the body if it's more than one statement. Perl requires both condition and body to be bracketed.

I have to ask why no language (that I know of, at least) requires brackets around the body, but not around the conditional. I would think that, as you say, if you explicitly define the body, then the conditional should be defined implicitly by the bounds set by the conditional command and the body...so what am I missing that all these other languages don't do this?

I was wondering exactly the same thing. As long as there is some sort of boundary between the condition and the body, the whole thing should be unambiguous. Item #140 of 5.4 versions.txt seems to imply this too:This seems to be the case in practice too, since I've never seen a statement break when only {}'s are used.

I share the same opinion.

Actually I think I've gotten the habit by seeing your snippets, hehe.

Imo it is a lot cleaner and provides more readability without using brackets.

mIRC Script is mIRC Script, it's not java, C++, PHP, whatever. I can understand how programmers feel mIRC should follow the standard of those other languages. Though I think most scripters aren't real programmers (in comparison), and those who are, will adapt easily to using brackets in those other languages.

I can't imagine mIRC changing now regarding the use of brackets. The way I see it, everyone creates his own style of scripting. Some are going to prefer things one way, others the other way. And since our current way works well if used accordingly, there should be no need to change it.

Greets

"mIRC Script is mIRC Script, it's not java, C++, PHP, whatever."

Agreed - In fact, I'm getting rather bored with people constantly saying how mIRC script should follow the principals and rules that those other languages follow. People learn mIRC script, they trot off around the cyber world for a couple of years and learn other languages, then they come back here and say how mIRC script isn't following this and that standard and it should do this and that like This and That++ does.

Khaled just gave a reason for it not being changed despite the fact that he has thought about it.

I understand why people who code a lot and know other languages may get mixed up between this and others, but it's just an IRC client, it's not meant to be setting some sort of Internet standard. mIRC does what it does, and has exceeded the expectations, I feel, of thousands of people. I'm sure that in the future it will develop even more (look how far it's come in 5 years, quite amusing browsing over versions.txt). BUT I don't agree with the constant comparisons made between mIRC scripting and C/C++/Java/PHP/etc..

My 2 cents

Regards,

mIRC Script is mIRC Script, it's not java, C++, PHP, whatever.

And since our current way works well if used accordingly, there should be no need to change it.

Both good points:

1) So what if PHP/C/C++ requires ()? Why should mIRC be made similar to these languages? I can only understand Khaled's point of view; required ()'s would probably simplify the parsing process, which means less work on the parser. But the reason users want the () required still escapes me.

2) "if it ain't broke don't fix it" applies well here

I don't think it should be changed, the only problems i've ever run into by not using { } is people saying it's "messy" and "hard to read" code.

Most statements aren't "strict" about the syntax you use at all:

if 1 { echo -a 1 }
if (1) echo -a 1
if (1) { echo -a 1 }

1) requiring ()'s would make parsing easier, so also quicker --> I can live with quicker scripts
2) Read the first post: it is broken...

I for one wouldn't mind if Khaled made the () around conditions required. Maybe make a few intermediate mIRc versions that give a warning when an if isn't followed by a (. Yes i would need to fix some scripts myself maybe, but that should be easy (ctrl-f, type if and hit F3 a lot). I mean, if even a parser can see the difference between condition and command, a scripter can do it too
I you want I'll think about a script to find all incorrect entries so you don't have to read all if's

1) Without seeing this implemented, we can't know if the speed difference would be significant. Personally, I'm willing to sacrifice a few microseconds for keeping () optional.

2) You missed the point. I never said that {} and () should be optional at the same time. I said that either should be required. Ie if you don't want to use ()'s you HAVE to use {}'s and vice-versa.