mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#178031 04/06/07 05:04 PM
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
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

Last edited by NaquadaServ; 04/06/07 05:16 PM.

NaquadaBomb
www.mirc-dll.com
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
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.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
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
}

Last edited by NaquadaServ; 04/06/07 08:12 PM.

NaquadaBomb
www.mirc-dll.com
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
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.

Last edited by NaquadaServ; 04/06/07 08:22 PM.

NaquadaBomb
www.mirc-dll.com
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
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.

Last edited by NaquadaServ; 04/06/07 08:42 PM.

NaquadaBomb
www.mirc-dll.com
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
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.

Last edited by NaquadaServ; 04/06/07 09:08 PM.

NaquadaBomb
www.mirc-dll.com
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
All means besides the first one violate mIRC syntax in other ways (should generate an error).

Last edited by NaquadaServ; 04/06/07 09:11 PM.

NaquadaBomb
www.mirc-dll.com
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
Why not just use proper syntax?

Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
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.

Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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?!


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
To all three prior replies: I'm sorry, I'm not going to teach a course in logic here.


NaquadaBomb
www.mirc-dll.com
Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
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.


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
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.

Last edited by NaquadaServ; 04/06/07 11:47 PM.

NaquadaBomb
www.mirc-dll.com
Joined: Dec 2002
Posts: 2,031
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,031
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?

Joined: Jul 2003
Posts: 655
Fjord artisan
Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
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.


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
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?

Last edited by qwerty; 05/06/07 10:23 AM.

/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Dec 2002
Posts: 580
N
Fjord artisan
OP Offline
Fjord artisan
N
Joined: Dec 2002
Posts: 580
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!


NaquadaBomb
www.mirc-dll.com
Page 1 of 2 1 2

Link Copied to Clipboard