5 replies to this topic

[Iggy_]

Var := ([whatever)

Gives compile error: Test.ahk (3) : ==> Missing "("
AHK_L 1.1.2.2

The sneaky bugger had me chasing round brackets everywhere for few minutes :?

[Lexikos]

How do you decide what is "missing"?

Var := [color=red][whatever)[/color]]
Var := ([color=red][whatever)[/color]

Maybe 'Unexpected ")"' would be more accurate.

[Iggy_]

Usually I decide what's missing when I put it back in and the error goes away
But that's not what you mean is it?
I dunno how the lexer works, or all the possible AHK syntax, it just seemed kind of strange.

What you suggest would be a bit better though I think.

There was only 1 missing bracket in this case though, in the whole script actually, so it was able to count all brackets it could have known that way.

[Lexikos]

When the expression parser encounters a close-parentheses token, it pops operators off the stack until it encounters the matching open-parentheses. If it encounters an open-bracket ("["), an open-brace ("{") or the beginning of the stack, there must be something missing - either "(" or "]"/"}". It could search the rest of the stack and the expression to the right of ")" to try to guess more accurately what the user's mistake was, but for error-checking that would be overkill. And it might still be wrong.

[Iggy_]

I see, thanks for the explanation.

Would it be possible for the message to say what the expression parser found which caused it to stop/error, as well as what it was expecting to find?
e.g: for Var := ([whatever)

Expected "(" but encountered "["

I think, if your mistake is leaving something out then the message is good, however when your mistake is putting something in which shouldn't be there, only knowing what the parser was looking for is not particularly helpful, especially if you don't understand how the parser works.

[Lexikos]

I'd considered that before, but decided it wasn't worth the extra code. That section of code only deals with symbols (arbitrary numbers/members of an enumeration) and doesn't know which character it originally came from.

Furthermore, I think it wouldn't be obvious to many users how or why it "encountered" whatever symbol it encountered. I suppose it's much more intuitive to scan forward, i.e. when they encounter "(", look for the corresponding ")". So in your example, a user might expect a message like 'Missing "]" before ")"'.

Since it's hard to say for certain what the user is expecting, I'd like to keep it simple - I think that 'Unexpected ")"' has the least potential for confusion.