mIRC Homepage
Posted By: NaquadaServ Script parsing bug? - 04/06/07 05:04 PM
Code:
alias bug while $for(4) if (%for == 3) $forreturn(%for)
alias nobug while $for(4) { if (%for == 3) $forreturn(%for) }
alias nobug2 while ($for(4)) if (%for == 3) $forreturn(%for)
alias -l for {
  if (%for < $1) || (%for == $null) { inc %for | return $true }
  set %for 0 | return $false
}
alias -l forreturn { set %for 0 | return return $1 }


Should this be a bug? Why are the curly brackets or parentheses needed for the while loop?

if has a single command of $forreturn and while has the the single command of if

Edit: /bug error message

* /while: 'if' unknown operator

Thus, it's the begining of the command, not an error... smile
Posted By: qwerty Re: Script parsing bug? - 04/06/07 06:34 PM
Originally Posted By: help file
If an alias uses too few brackets then the statement might be ambiguous and the alias will take longer to parse, might be parsed incorrectly, or might not be parsed at all.
Omitting both () and {} creates an inherently ambiguous piece of code and there's nothing mirc can do about that. It already does its best to parse statements with fewer brackets (which is why omitting either () or {} works). For example, how should mirc know that $for() is meant to be the entire condition and not just the first operand? Just because $for() returns $true/$false doesn't mean it should be considered the entire condition: remember there are no real types in mirc scripting.
Posted By: NaquadaServ Re: Script parsing bug? - 04/06/07 07:51 PM
The error is unknown operator, so the parser must already know there is a $v1 (if it's looking for an operator)... All I'm saying is that instead of an error, $v1 should be evaluated on it's own, then the /bug alias would work.

I can't imagine this breaking any existing script. It also should be only a small change in code, handling the error rather than generating an error message. All it's doing is making the parser "smarter".

Code:
alias bug while $true if $true break
smile

Edit: On a side note it would be nice if this was allowed without using $& (terrible looking in scripts)...
Code:
alias multipleLineStatements
{
  if $true
    singleStatementBecauseNoCurlyBrackets
  while $true
    break
}
Posted By: starbucks_mafia Re: Script parsing bug? - 04/06/07 08:00 PM
But then if there is a real error in the syntax it becomes harder to spot.

I'd much prefer ambiguous code to present errors rather than have mIRC bending over backwards to accommodate poor coding. That way everyone wins: code is faster and more readable, and scripters making genuine errors can quickly find them.
Posted By: NaquadaServ Re: Script parsing bug? - 04/06/07 08:07 PM
Originally Posted By: starbucks_mafia
But then if there is a real error in the syntax it becomes harder to spot.

I'd much prefer ambiguous code to present errors rather than have mIRC bending over backwards to accommodate poor coding. That way everyone wins: code is faster and more readable, and scripters making genuine errors can quickly find them.


I don't see how handling this error would change error messages for those people that already use ()...

Also, Take this for example..
Code:
alias bug while $for(4) bad_command


This /bug returns the error...

/while: invalid format

I think this second one should be a bad command (message from the server)...

Edit: I also can not see how this would reducing the speed of the parser when using () or {}, since this condition is only evaluated when missing () or {}. It might even speed it up, generating other errors earlier... wink

Edit2: Let also face the fact that the parser, even now, doesn't always return the most meaningful indication of the actual error.
Posted By: starbucks_mafia Re: Script parsing bug? - 04/06/07 08:20 PM
Quote:
I don't see how handling this error would change error messages for those people that already use ()...

I'm not talking about people who use (), I'm talking about people who use no formatting at all, as in your "bug" case. It makes sense that at a certain point mIRC shouldn't try and guess what the scripter meant and instead should raise an error saying "I don't know what you want me to do here". I'm sure it could guess in the way you're suggesting, and in some instances that would produce the intended result, but why resort to guessing when raising an error allows the scripter to fix the code.

Quote:
Edit: I also can not see how this would reducing the speed of the parser when using () or {}, since this condition is only evaluated when missing () or {}.

It wouldn't slow down properly written code. Ambiguous code lacking () and {} is slower than code which plus supplies one or both of those. I'm saying that by raising an error and making the scripter fix their dubious code it means the code will be faster. Not in itself a big deal, but just another little incentive for mIRC to enforce proper syntax.
Posted By: NaquadaServ Re: Script parsing bug? - 04/06/07 08:33 PM
Originally Posted By: starbucks_mafia
It makes sense that at a certain point mIRC shouldn't try and guess what the scripter meant and instead should raise an error saying "I don't know what you want me to do here". I'm sure it could guess in the way you're suggesting, and in some instances that would produce the intended result, but why resort to guessing when raising an error allows the scripter to fix the code.

Guess how? A guess implies a choice in how to handle the error, a choice that doesn't include generating an error message, since it is not handling the error then; or in other words a different way that the script could be interpeted. So please, tell me some other way to parse (without generating an error)...

Code:
alias bug while $true if $true break

Please be sure your reply doesn't break existing mIRC syntax.
Posted By: starbucks_mafia Re: Script parsing bug? - 04/06/07 08:51 PM
In that specific example there is only one non-error way to interpret the code. That's obviously not always going to be the case.

Code:
alias bug while 1 if $me == 1 if starbucks_mafia break


Did I mean:
Code:
alias bug while (1) if ($me == 1) if (starbucks_mafia) break

or
Code:
alias bug while (1 if $me == 1) if (starbucks_mafia) break

or
Code:
alias bug while (1 if $me == 1 if) starbucks_mafia break

or
Code:
alias bug while (1 if $me == 1 if starbucks_mafia) break

or was it a typo that should raise an error?

You're suggesting that mIRC should guess. I'm saying mIRC should "ask" by raising an error and requiring the scripter to clarify his code.

Even if there is only one non-error producing way to interpret the code mIRC would still be guessing that it isn't in fact a genuine error in the code. That would be a mistake in my opinion. There's nothing wrong with generating errors when applicable, it's definitely preferable to trying to make up for poor code.
Posted By: NaquadaServ Re: Script parsing bug? - 04/06/07 08:55 PM
To summarize, this is another situation where sometimes it works, sometimes it doesn't. link

Code:
; Doesn't use () or {}, but this works
alias works if $true == $true return
; Doesn't work
alias nope if $true return

And as far is the link (above) is concerned, with /var and no equals sign, that is an example of where an error message would be missing, or handling the no equal sign should be implemented.

I'm done talking about both points; I have made clear arguments for both.
Posted By: NaquadaServ Re: Script parsing bug? - 04/06/07 08:59 PM
All means besides the first one violate mIRC syntax in other ways (should generate an error).
Posted By: RoCk Re: Script parsing bug? - 04/06/07 09:06 PM
Why not just use proper syntax?
Posted By: hixxy Re: Script parsing bug? - 04/06/07 09:09 PM
I can't believe you're actually arguing for this suggestion.

There's no way mIRC should try and guess what you're trying to do, just to save you typing a couple of extra characters.

Even with something like:

Code:
if $true echo -a hi!


How should mIRC know what I'm trying to do? /echo is a valid alias name. /-a is a valid alias name. /hi! is a valid alias name. Maybe I want to do if ($true echo) -a hi

I'm with Starbucks and think that mIRC should raise an error.
Posted By: starbucks_mafia Re: Script parsing bug? - 04/06/07 09:15 PM
Quote:
All means besides the first one violate mIRC syntax in other ways (should generate an error).

How do you figure that? All the possibilities I posted there are unambiguous valid code. You're suggesting they should generate an error but the original ambiguous code shouldn't?!
Posted By: NaquadaServ Re: Script parsing bug? - 04/06/07 11:41 PM
To all three prior replies: I'm sorry, I'm not going to teach a course in logic here.
Posted By: Om3n Re: Script parsing bug? - 04/06/07 11:42 PM
Originally Posted By: NaquadaServ
All I'm saying is that instead of an error, $v1 should be evaluated on it's own, then the /bug alias would work.

This would prevent any legitimate operator errors from being raised if scripted in the same brace-less manner.

Code:
alias test while %match iswn %data modify %data

this would try to execute "/iswn %data modify %data", instead of the intended "/modify %data", in THIS case it would throw a DIFFERENT error making the problem harder to digest. But this is assuming any such mistype doesnt exist in aliases, which it very well could and would then call the alias and the coder may be left with a broken script but not even knowing about.

I do not think mirc should make this assumption, it should throw the error as it currently does.
Posted By: NaquadaServ Re: Script parsing bug? - 04/06/07 11:47 PM
Originally Posted By: Om3n
Originally Posted By: NaquadaServ
All I'm saying is that instead of an error, $v1 should be evaluated on it's own, then the /bug alias would work.

This would prevent any legitimate operator errors from being raised if scripted in the same brace-less manner.


Why? If an operator then take a $v2 (if needed), otherwise just evaluate $v1... If not an operator then, it's a command.

I guess I'm not saying this correctly, because for the life of me I can't see why everyone opposes this.
Posted By: RoCk Re: Script parsing bug? - 05/06/07 12:27 AM
So everyone else is wrong and you're right? For the life of me I can't see why you can't just use proper syntax?
Posted By: Om3n Re: Script parsing bug? - 05/06/07 06:53 AM
What if their was an alias with the same name as a mistyped operator, or a mistyped alias call was a valid operator, in these circumstances (more common than you might think) mirc would no longer throw the appropriate error to bring attention to the issue, it would instead 'handle' it and possibly perform a task incorrectly without any warning or knowledge to the coder.

My point was, although the code would SEEM to function correctly at a glance, it could easily perform the wrong tasks based on any number of circumstance (in my example a mistype). In such cases where mIRC would normally throw an error and allow somebody to find and fix the error quickly, it no longer would.

All in all i guess i dont think script debugging should be made harder, for the sake of accomodating lazy or sloppy code.

The only language i can think of that does anything similar to this is SQL, and im guessing the only way it gets away with it is because it knows all the possible commands that can follow. Unlike sql mirc can have commands named the same as the operators.

Maybe i am completely misunderstanding or overlooking something, because i cant see why this would be an advantage in the single-line type examples you gave. Multiple line code may have better results, as mirc could use the linebreak to determine the end of the condition and the start of the command (similar to the way it treats pipes in single line code). Although im certainly not in favour of encouraging braceless code, i think its a bonus that mirc allows it on any level at all.
Posted By: qwerty Re: Script parsing bug? - 05/06/07 08:34 AM
Quote:
I guess I'm not saying this correctly, because for the life of me I can't see why everyone opposes this.
starbucks_mafia already explained that, but let me spell it out for you one last time: the reason everyone opposes this is that its only effect would be encouraging people to write unreadable, ambiguous and hard to debug code. It already encourages bad practise by allowing some statements to be parsed (eg "if $true == $true return") and you want to push it further to that direction...

So the real question is, why are you suggesting this? It all started with a bug report, you were shown it's not a bug (help file clearly states what you should/should not do), why did you turn it into a feature suggestion when that feature can only make things worse?
Posted By: NaquadaServ Re: Script parsing bug? - 05/06/07 11:41 AM
Originally Posted By: qwerty
It (mIRC) already encourages bad practise by allowing some statements to be parsed (eg "if $true == $true return") and you want to push it further to that direction...

So the real question is, why are you suggesting this?


You just answered your own question. As I have stated before!
Posted By: starbucks_mafia Re: Script parsing bug? - 05/06/07 02:16 PM
So because mIRC supports some bad habits you think it should support more?

It may be awkward to remove the current allowances due to backwards compatability, but that's absolutely no reason to encourage more poor code by making mIRC play parser-detective.

You seem to have some kind of pathological phobia of errors. There's nothing wrong with them. They're downright vital in fact. When code's meaning isn't clear - that's an error. Trying to sweep them under the carpet with guesswork doesn't help anybody.
Posted By: hixxy Re: Script parsing bug? - 05/06/07 05:20 PM
Originally Posted By: NaquadaServ
To all three prior replies: I'm sorry, I'm not going to teach a course in logic here.


Good. You're not qualified.
Posted By: Riamus2 Re: Script parsing bug? - 05/06/07 06:37 PM
starbucks_mafia is right. Bad coding practices shouldn't be encouraged even if some bad practices are already possible in mIRC. Write code using proper syntax and you'll save everyone a lot of headaches. I absolutely hate trying to debug code that is written using invalid syntax or written in such a way as to make it difficult to read clearly (such as tons of commands on a single line using pipes). It's just not helpful to anyone.
Posted By: NaquadaServ Re: Script parsing bug? - 05/06/07 08:16 PM
Proper syntax is flawed, all I'm saying is make it consistent. Eliminate the sometimes is does, sometimes it doesn't situations.

Thankfully the decision is not up to all of you, it Khaled's decision. I assume (unlike I can for the rest of you) that he actually has a computer science degree, and can fully understand my argument.

Posted By: RoCk Re: Script parsing bug? - 05/06/07 08:20 PM
I can understand that it should be consistent, but if anything were to be changed, it should go the opposite way from where you want it to go.

~ Edit ~

lmao .. so now everyone else is stupid and uneducated because they don't see things your way?
Posted By: NaquadaServ Re: Script parsing bug? - 05/06/07 09:08 PM
Originally Posted By: RoCk
I can understand that it should be consistent, but if anything were to be changed, it should go the opposite way from where you want it to go.

I agree, but do you honestly think that (killing backwards compatibility) would go over well here? I'm arguing the only backwards compatible method to resolve these inconsistencies.

Originally Posted By: RoCk
lmao .. so now everyone else is stupid and uneducated because they don't see things your way?


No, not stupid, far from it, just less skilled/experienced. I didn't say everyone, only commenting on those people that responded earlier to this thread. It's also an assumption, nothing more.
Posted By: hixxy Re: Script parsing bug? - 05/06/07 09:16 PM
It's a minor inconsistency that has gone almost unnoticed for years because nobody wants to write such tacky code. Fixing this inconsistency will not really benefit the users of the program, but it will make code harder to debug for people unaware of the correct syntax. It may be an inconsistency, but it's a useful one.
Posted By: starbucks_mafia Re: Script parsing bug? - 05/06/07 09:20 PM
Quote:

I agree, but do you honestly think that (killing backwards compatibility) would go over well here? I'm arguing the only backwards compatible method to resolve these inconsistencies.

The fundamental flaw in your logic here is that most people would rather see less scope for poor code at the cost of letting the inconsistency remain. Personally I'd be quite happy to see backwards compatability broken in this case to enforce the use of () or {}.

But that's probably just my lack of skill and experience talking.
Posted By: NaquadaServ Re: Script parsing bug? - 05/06/07 09:30 PM
Originally Posted By: starbucks_mafia
Personally I'd be quite happy to see backwards compatability broken in this case to enforce the use of () or {}.

At least I partially got through to someone.

Originally Posted By: starbucks_mafia
But that's probably just my lack of skill and experience talking.

Love the sarcasm... smile
Posted By: Riamus2 Re: Script parsing bug? - 06/06/07 03:30 AM
Considering that I do have a degree and have a very good understanding of computers and programming and have even taught both, I think your assumption is invalid. And I'm sure the same can be said for most others here as well (especially those who are regular helpers).

Now. Consistancy is a good thing. However, as has been mentioned, you should *not* make it consistant by allowing more bad coding styles. That is a bad argument, pure and simple. Forcing only valid syntax (ie. good coding styles) is not a bad thing.

So the question comes up... should we break all of the scripts that use bad coding that currently work because mIRC lets some things slip by so that coding is consistant -- you either use valid code or it won't work, or do we leave things as they are so that no scripts are broken, but coding styles cannot deteriorate further than they already are.

That's a difficult question because you don't want to break as many scripts as those changes would break. However, mIRC has made changes that forced better coding (6.20 did that) and it did break some scripts that weren't coded correctly. Of course, those changes were to actual errors rather than dropping sets of ()'s and {}'s, so forcing people to fix those was more valid than forcing them to add in all of the missing ()'s and {}'s. Even so, it is a precedent to forcing valid code. The question remains as to wheter Khaled will do that. Personally, I think valid syntax should always be required. It makes debugging a LOT easier and it also makes for less chance of producing errors.

In any case, I think everyone here (and most likely Khaled as well) will agree that mIRC should *not* allow *more* bad coding, no matter what. The real question is whether or not to force good coding for the items that can currently be coded "badly" and still work. You'd have support for that suggestion, but you won't have support for lowering the coding syntax requirements.
Posted By: RusselB Re: Script parsing bug? - 06/06/07 07:04 AM
RusselB nominates Riamus for President laugh You've got my vote
Posted By: hixxy Re: Script parsing bug? - 06/06/07 08:10 AM
I say leave it as it is. Using only one set of brackets isn't even what I'd call 'bad' coding, as it's still very clear what you're trying to do.

Code:
if x == y { do this }
if (x == y) do this
if (x == y) { do this }


There's absolutely no ambiguity in any of those statements. In this however:

Code:
if x == y do this


There is.
Posted By: Om3n Re: Script parsing bug? - 06/06/07 08:54 AM
Originally Posted By: NaquadaServ
Originally Posted By: starbucks_mafia
Personally I'd be quite happy to see backwards compatability broken in this case to enforce the use of () or {}.

At least I partially got through to someone.


You are assuming nobody else had these thoughts, which is far from accurate. The thing is, your posts were suggesting the opposit.

Personally, i'd prefer to see the forced use of correct syntax (braces etc), rather than accomodate less use of correct syntax.

I doubt this will be changed either way, because BOTH way would break some scripts. Granted that forcing the use of braces in all cases would break more, there would still be a few that the other way would break, or alter the behavior of, due to the underlying logic change.

As for your rediculas assumptions about CS degrees and lack of understanding, you were wrong.
Posted By: RoCk Re: Script parsing bug? - 06/06/07 12:25 PM
Ditto here hixxy, I think that unless the syntax is going to be enforced 100%, there has to be a line (tolerance). The example given in the OP of this thread not only exceeded that line, but kicked the lines dog, insulted its mother and then complained because the line didn't say thank you. The line is fine where it is.
Posted By: Riamus2 Re: Script parsing bug? - 06/06/07 01:41 PM
Originally Posted By: hixxy
I say leave it as it is. Using only one set of brackets isn't even what I'd call 'bad' coding, as it's still very clear what you're trying to do.


That's why I put quotes around "badly". I think leaving it as-is would be fine. Making it less strict would be bad. Making it more strict wouldn't necessarily be bad, but would break enough scripts that I doubt it would happen. Besides, the current method has worked perfectly fine for a long time, so there really isn't a reason to change it, so I agree with you. smile
© mIRC Discussion Forums