Please check for syntax that doesn't make ANY sense

[Little John]

In the following code, I think the compiler should raise a syntax error on the 3rd line, but it doesn't do so (PB 4.51 Windows x86):

Code: Select all

s$ = "abcd"
Debug Mid(s$, 2)
Mid(s$, 2)

I had something like that by accident in my code, and it wasn't easy for me to find the bug in my program. I would appeciate if the compiler criticizes all syntax errors.

Regards, Little John

[Trond]

Why on earth would it do that?

[Little John]

Why on earth would it do that?

What would do what?

[eesau]

I can't find the error in your code.

[Little John]

I can't find the error in your code.

So

Code: Select all

Mid(s$, 2)

is a valid command?

[Mistrel]

I'm going to take a stab at this.. is it because your function is supposed to return a value and you're not using it? That's well beyond anything the compiler should ever care about.

[eesau]

So

Code: Select all

Mid(s$, 2)

is a valid command?

Sure. Just because the return value is not used it isn't a syntax error. Maybe an optional warning could be generated.

[Little John]

So

Code: Select all

Mid(s$, 2)

is a valid command?

Sure. Just because the return value is not used it isn't a syntax error. Maybe an optional warning could be generated.

PB has other built-in functions, that work fine without using their return value, e.g. OpenWindow(). In theses cases, of course it's up to the PB programmer whether or not to use the return value.

But ignoring the return value of Mid() doesn't make any sense, so of course it's a syntax error. What else could it be?? Anyway, I don't want to start a "philosophical" discussion what a syntax error is and what it isn't. But nobody who knows the syntax rules of PureBasic would deliberately write

Code: Select all

Mid(s$, 2)

So it can only be some kind of mistake. Since to err is human, since we want to a have as few bugs in our code as possible, and since the compiler is a programming tool for humans, it obviously would be helpful if the compiler criticized such wrong code.

[PB]

> of course it's a syntax error

Nope: http://en.wikipedia.org/wiki/Syntax_error

> What else could it be?

A logic error: http://en.wikipedia.org/wiki/Logic_error

[Trond]

The compiler can't know whether a function has side effects.

[c4s]

When I'm loading a file that doesn't exist the compiler raises a warning (code line gets orange). Such a warning would be nice in this case as well.

@Yes, you're right. But the compiler knows it for the internal functions and this could be enough.

[Little John]

Nope

I disagree with your opinion. However, as I wrote that's not the point here. Call it however you like.

The compiler can't know whether a function has side effects.

What has this got to do with the problem at hand?
The compiler could help the programmer to find this kind of "wrong code" (or however we call it). So I just wish it would do so.

But the compiler knows it for the internal functions and this could be enough.

Yes, I'm only talking about internal functions, of course. I'm sorry in case I didn't make that point clear enough previously. The compiler "knows" all internal functions, and so it knows that e.g. the line

Code: Select all

Mid(s$, 2)

doesn't make any sense.

There are programming languages that raise an error in exactly the case that I'm talking about. The error message reads e.g.

function result must be assigned or used

In principle there is no problem building this kind of error check into PureBasic, and it won't do any harm either.
Whether or not Fantaisie software wants to do so, is a different question.

[Trond]

The compiler can't know whether a function has side effects.

What has this got to do with the problem at hand?
The compiler could help the programmer to find this kind of "wrong code" (or however we call it). So I just wish it would do so.

If the function had side effects (like OpenWindow()) it could be that you only wanted the side effects, and didn't want the return value. It would be annoying if the compiler put an error in this case.

But the compiler knows it for the internal functions and this could be enough.

Yes, I'm only talking about internal functions, of course. I'm sorry in case I didn't make that point clear enough previously. The compiler "knows" all internal functions, and so it knows that e.g. the line

Code: Select all

Mid(s$, 2)

doesn't make any sense.

No, the compiler doesn't know how the internal functions work. The compiler doesn't know that Mid() doesn't have side effects while OpenWindow() does. Because these function reside in library files, and the compiler only known their names, parameters and return type.

There are programming languages that raise an error in exactly the case that I'm talking about.

In that case there needs to be a "void" return type to signify that the function doesn't return any value. PB doesn't have such type.

And there are many functions where the return value is not always needed. What would you do about those? The compiler can't know this difference:

Code: Select all

CreateImage(0, 10, 10) ; Return value available, but not needed
CreateImage(#PB_Any, 10, 10) ; Return value needed

[Little John]

The compiler can't know whether a function has side effects.

What has this got to do with the problem at hand?
The compiler could help the programmer to find this kind of "wrong code" (or however we call it). So I just wish it would do so.

If the function had side effects (like OpenWindow()) it could be that you only wanted the side effects, and didn't want the return value. It would be annoying if the compiler put an error in this case.

Ah, now I understand what you mean. Yes, I agree.
My wish refers only to functions such as Mid(), where ignoring the return value doesn't make any sense. I have written that repeatedly, for details please see my previous posts.

the compiler only known their names, parameters and return type.

There are programming languages that raise an error in exactly the case that I'm talking about.

In that case there needs to be a "void" return type to signify that the function doesn't return any value. PB doesn't have such type.

Such a type can be built into PB, no? I wrote my wish here, but I'm sure the PB team will know better than me how to implement it in detail.

And there are many functions where the return value is not always needed. What would you do about those?

My wish refers only to internal functions such as Mid(), where ignoring the return value doesn't make any sense. Implementing my wish will not cause any disadvantage to the PB programmer.

[freak]

And there are many functions where the return value is not always needed. What would you do about those?

My wish refers only to internal functions such as Mid(), where ignoring the return value doesn't make any sense. Implementing my wish will not cause any disadvantage to the PB programmer.

The compiler has to be consistent in its error reporting. Otherwise it just creates confusion. How is a beginner supposed to know that for function X the returnvalue is always needed and for function Y it can sometimes be ignored? For him it will just look like the compiler is missing an error.

"When i make the same mistake multiple times, the compiler only notices half of them. This compiler is not reliable!"

If anything, this could be a warning not an error.