Time consuming compiler messages

[norbert doerre]

Following is a small code extraction.
The compiler says:
"Parameter mismatches definition - A parameter used in a call to a procedure does not match (or cannot be converted to) the data type or reference type (BYREF, BYVAL, BYCOPY) found in the procedure declaration/definition."
The line logged by the compiler was that with the "@" sign.

Here the code:
'
'
'
'Maßlayer abfragen
iRet = VCGetDimUseDimLayer(iError)
SetMenuItemCheck("Maßlayer verwenden", iRet)

'Textlayer abfragen
iRet = VCGetTextUseTextLayer(iError)
SetMenuItemCheck("Textlayer verwenden", iRet)

'Schraffurlayer abfragen
@ iRet = VCGetHatchLayer, iError, tfUsed)
iHatchLayerIndex = iRet
tfHatchLayerUsed = tfUsed
SetMenuItemCheck("Schraffurlayer verwenden", iRet

'Layerparameter abfragen
iRet = VCGetDrawingUsedByLayerProperties(iError)
SetMenuItemCheck("Parameter verwenden", iRet)
end sub

Solution of the puzzle:

What I did not notice at once, is the missing ")" in one line.
I think that such error messages could lead do time consuming actions.

[Michael Mattias]

FWIW, I have suggested 480 be updated/enhanced/supplemented/replaced with multiple messages, one for each programming error resulting in this code.

• Mismatched left-right parentheses (number of left <> number of right)
• Parameter count in call does not match parameter count of procedure definition
• Comma expected [ you get 480 if you forget a comma between params]
• Parameter data type for this parameter does not match datatype in procedure definition [the current message]

Send in your own New Feature Suggestion for the same thing and you can get the much-coveted "checkmark."

[Bob Zale]

Absolutely correct, Norbert.

When you type a line of source code with an error in it, there is a certain amount of time consumed for you to go back and correct the error. It's too bad the compiler couldn't "know" what you want and rewrite your code for you...

The compiler was expecting to see two parameters. But, with no open parentheses, it looked like you were trying to reference it with zero parameters. Hence, the most likely problem was a mismatch of parameters, compared to the original declaration.

Luckily, the compiler told you not only the precise line where your error occurred, but it also pointed to the approximate column within that line. Quite a deal, isn't it? {smile}

Thanks!

Bob Zale
PowerBASIC Inc.

[Chris Holbrook]

it looked like you were trying to reference it with zero parameters.

If so, then the error message obtained was perhaps not the best choice as it said "A parameter used in a call to a procedure does not match ". "A parameter" is not "zero parameters".

I hate to split hairs, but that is what error messages are about. I have few complaints about PB error messages maybe because after years of working with cc, I don't really look at error messages expecting much information apart from line number, if that!

[Bob Zale]

I appreciate your complaint, Chris. Thank you.

Bob Zale
PowerBASIC Inc.

[Mel Bishop]

...It's too bad the compiler couldn't "know" what you want and rewrite...

He/She/They would be richer that Queen Elizabeth and bill gates combined if someone wrote a compiler that does what you MEAN for it to do instead of what you TELL it to do.

[Bob Zale]

• Mismatched left-right parentheses (number of left <> number of right)
• Parameter count in call does not match parameter count of procedure definition
• Comma expected [ you get 480 if you forget a comma between params]
• Parameter data type for this parameter does not match datatype in procedure definition [the current message]

There's a certain logic to errors 2,3,4. The first is highly impractical since you can't really parse your way over to the close paren when you have many problems with expressions and delimiters much earlier in the statement. Actually, the only error message which makes more sense than a "Parameter mismatches definition" (in this case) might be "Open parentheses expected". Of course, that only applies when you use parentheses, which would not apply if there is no return value.

Therefore, we have to consider consistency. Since we can't give the "open paren" error when there's no return value, maybe it's best to just give you the same error in both cases: "Parameter Mismatches Definition". In this case, the compiler points to the comma and tells you that parameters given here don't match the original declaration. That doesn't seem to be too far from reality... at least not to me. I'd look at the DECLARE, then look at the comma, and say "by gosh, I don't think that comma represents a valid parameter!". Where have I gone wrong?

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

I was thinking when you parse and edit any line of code, one of the first checks you should do regardless of content or context is count left parens and right parens outside of quoted strings, since it is impossible to have a valid line of source code if the left-right paren counts don't match.

Not that this foolproof: You could have mismatched double quotes - which IS legal (but only if there is an implied double-quote 'at end?') - and trying to figure out if a particular paren is 'supposed' to be part of a literal might get hairy.

Then again, you and your people have been parsing source code for a very long time and if anybody can do it I would think it would be you guys.



MCM

[Bob Zale]

Well, we just don't do that. We never scan ahead, because any errors we might detect in that fashion could easily give the programmer a false sense of security.

If we find an extra right parentheses at position (column) number 224, then point to it and display "Mismatched parentheses", some of the folks will think that the first 223 characters are "A-OK", when we've never even looked at them. We'd much rather move from left to right and stop as soon as find something which cannot be compiled.

Do you have any idea how many complaints we get because we find some errors in pass one? For example, pass one finds an error in line number 900. You fix it, and then pass two finds an error in line 10. You scream and holler that line 10 compiled perfectly last time! Why not now? That's why we only report errors in pass one when there is absolutely no other possibility available. Same principle in left to right parsing.

Now that I've given away all of our trade secrets, you may resume thinking up even more error codes to suggest. {smile}

Bob Zale
PowerBASIC Inc.

[norbert doerre]

But Bob, You honestly may admit that it is better to get first an error log in line 1000, correct it and then another one in line 10 and correct it, too. Much better than to get only one error code in line 10, where in fact no bug exists, but it could finally be found MANUALLY in line 1000.

Bob, the problem is not the really splended result of PB compiler which in my opinion is perhaps the best for the MS market, the problem is now an then a very much time consuming error logging which can hinder successfull business, mostly in cases when You need a quick success.

[Bob Zale]

Much better than to get only one error code in line 10, where in fact no bug exists, but it could finally be found MANUALLY in line 1000.

If that were true, it's likely I would agree with you. Fortunately, it is not true. Or, at least, it has surely not been demonstrated.

Are you suggesting you can show me an example of such a situation? If so, why are you holding it back?

Bob Zale
PowerBASIC Inc.

[Edwin Knoppert]

This week i had such one again, annoyed but i strongly recommend not to change it.
It's like Option Explicit, something which should be turned on by default imo.
(Afaik PBEDIT 'throws' it in)

I do find code from the old ages where this was allowed:

hval = SendMessage hwnd, msg, wparam, lparam

Please remove defint, option base and such miserable commands which lead to non-modular coding.

[Bob Zale]

Edwin--

Norbert says he has code which reports and displays a compile-time error on line 10, but the compile-time error is really in line 1000. He has not shown an example. I have never heard of such a thing. Do you have an example of that specific issue?

One version of PowerBASIC allowed function references without parentheses. That error has since been corrected and does not exist in the current compilers. We're hopeful and confident this bug will not magically reappear.

Best regards,

Bob Zale
PowerBASIC Inc.

[Edwin Knoppert]

>One version of PowerBASIC allowed function references without parentheses. That error has since been corrected and does not exist in the current compilers. We're hopeful and confident this bug will not magically reappear.
I'm happy.

--

Note that i replied to this thread title, not the previous poster (1000 stuff).

[Bob Zale]

Happy is good.

[norbert doerre]

Bob, my 'line 1000' argument refers simply to Yours You wrote before:
<"For example, pass one finds an error in line number 900. You fix it, and then pass two finds an error in line 10. You scream and holler that line 10 compiled perfectly last time! Why not now? That's why we only report errors in pass one....">
What I mean is that logging errors should not produce results which are simply relying on lines but on a parser which is able to 'understand' the allowed syntax of code, because code is nearly as logical as math functions. A hint about wrong spelling or deficits in the syntax can quite simply be detected and then reported to the programmer related to lines to give a hint about the region where the bug is nested in. I'm happy with PB, because it is excellent enough not to produce additional own bugs. It gives therefore the best potential to reveal the programmer's syntax errors. So, in principle, the parser should always be much better than the coder. I'm shure, PB could do it, I don't know any other!

[colin glenn]

Absolutely correct, Norbert.

When you type a line of source code with an error in it, there is a certain amount of time consumed for you to go back and correct the error. It's too bad the compiler couldn't "know" what you want and rewrite your code for you...

The compiler was expecting to see two parameters. But, with no open parentheses, it looked like you were trying to reference it with zero parameters. Hence, the most likely problem was a mismatch of parameters, compared to the original declaration.

Luckily, the compiler told you not only the precise line where your error occurred, but it also pointed to the approximate column within that line. Quite a deal, isn't it? {smile}

Thanks!

Bob Zale
PowerBASIC Inc.

Not completely "Quite a deal", the help file could also include information on how else you can cause this error:

CLASS METHOD UpdateEntry(Index AS LONG, Element AS STRUCTURE)

ME.UpdateEntry Index, Element

Error 480 in source.BAS(55:032): Parameter mismatches definition
Line 55: ME.UpdateEntry Index, Element

Error 480 - Parameter mismatch, may need BYCOPY

You get used to using native functions without (), ...

Aside from trying a zillion different combination's of BYREF BYVAL BYCOPY plus making the METHOD return a value:
CLASS METHOD UpdateEntry(Index AS LONG, Element AS STRUCTURE) AS LONG

And expect a return value:
iResult = ME.UpdateEntry(Index) = Element
Of course the above was a fail, durr, and I tried it anyway!

But after a half hour of fighting this, it took a search of the forums to locate my issue.

And just to make things stranger, can't do what I originally planned, it would cause a data loss error!

Time to get some more :coffee: