Page 2 of 2
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 9:25 am
by Dude
I wasn't taking the default value into account. I thought you meant the variable itself wasn't being defined. Sorry!
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 9:35 am
by Kukulkan
Dude wrote:I wasn't taking the default value into account. I thought you meant the variable itself wasn't being defined. Sorry!
Both
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 9:49 am
by mhs
As you can see, the variable is defined by the compiler as a string:
Code: Select all
EnableExplicit
Procedure test()
If 1=0
Protected t.s = "Hallo"
EndIf
If Defined(t, #PB_Variable) : Debug "Defined" : EndIf
Debug TypeOf(t)
Debug #PB_String
EndProcedure
OpenConsole()
test()
CloseConsole()
However the default value is ignored. I think that's a question of design philosophy of the compiler.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 10:24 am
by Shield
Kukulkan wrote:I believe it is not. In such case, the value of t.s would have been "Hallo". But it is empty. Thus, the whole declaration was ignored.
There is a difference between declaration and definition. The declaration is moved to the beginning but of course the definition (= initialization)
must be kept on the same line, otherwise the program wouldn't be the same (for example in case of a function call to get the first value).
Kukulkan wrote:
Shield wrote:Say what? It's not undefined. The "Protected" keyword defines it, just like the manual says.
I didn't say this.
Kukulkan wrote:
My declaration of t.s contained a default value. This was ignored by the compiler as during the first usage of the variable it was empty. But this is not what I defined using "Protected".
Again, the *declaration* wasn't ignored. It has obviously been declared as mhs showed.
It hasn't been *defined* with your value since that assign statement has never been executed.
-> This is totally to be expected.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 10:27 am
by TI-994A
Kukulkan wrote:My declaration of t.s contained a default value. This was ignored by the compiler as during the first usage of the variable it was empty. But this is not what I defined using "Protected".
There appears to be some confusion in terms. Whether or not a variable definition is executed, the PureBasic compiler would still automatically
declare it. Only when a variable is
defined is it instantiated and assigned any default values.
That's the rule in C anyway.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 10:57 am
by Kukulkan
I just did some tests here to see how PB compares to other compilers:
C#
Code: Select all
using System;
public class Program
{
public static void Main()
{
int z = 0;
if (z == 1) {
String t = "Hallo";
}
Console.WriteLine(t);
}
}
-> Compilation error (line 10, col 21): The name 't' does not exist in the current context
VB.NET
Code: Select all
Imports System
Public Module Module1
Public Sub Main()
Dim z As Integer = 0
if z = 1 then
Dim t as string = "Hallo"
end if
Console.WriteLine(t)
End Sub
End Module
-> Compilation error (line 8, col 0): 't' is not declared. It may be inaccessible due to its protection level.
JS
Code: Select all
var z = 0;
if (z == 1) {
var t = "Hallo";
}
writeln("Out " + t);
-> the variable t is "undefined"
PHP
Code: Select all
$z = 0;
if ($z == 1) {
$t = "Hallo";
}
echo $t;
-> Notice: Undefined variable: t in [...][...] on line 5
I still think that PB should trigger, at least, some warning (like PHP does).
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 11:18 am
by Shield
This is because C# and VB.NET both have a notion of scopes, so t is only valid within the if block.
JavaScript and PHP report the variable as undefined because they are interpreted languages (or more correct,
they are treated as if they were interpreted), which is why the value is undefined (i.e. not initialized), because
the variable has not been defined before its first use. Both languages have no concept of "EnableExplicit".
Edit: the reason why PHP triggers a warning and PB doesn't is because PB knows that the variable exists,
since it has been declared (and found during compilation). PHP doesn't undergo a traditional compilation process,
so it cannot know that the variable exists, it only knows that it hasn't been initialized.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 12:52 pm
by TI-994A
Shield wrote:...the reason why PHP triggers a warning and PB doesn't is because PB knows that the variable exists, since it has been declared (and found during compilation).
Essentially, this is what PureBasic does to your code:
Code: Select all
Procedure test()
Protected t.s
If 1 = 1
t = "Hallo"
EndIf
PrintN(t)
EndProcedure
It declares the variable but does not initialise it with any default value.
Re: Shouldn't this trigger a compiler error?
Posted: Fri Nov 06, 2015 2:17 pm
by HanPBF
Code: Select all
EnableExplicit
Procedure test()
If Defined(t, #PB_Variable) : Debug "Defined 1" : EndIf
;debug t ; error if uncommented
If 1=0
Protected t.s = "Hallo"
EndIf
If Defined(t, #PB_Variable) : Debug "Defined 2" : EndIf
debug t
Debug TypeOf(t)
Debug #PB_String
EndProcedure
OpenConsole()
test()
CloseConsole()
Defined 1 is not in debug output; so starting with "Protected t" the variable is available.
As there is no local scope and no undefine(t, #PB_Variable) (while the latter in a compiler makes no sense), variables should be declared like in Pascal only at the beginning of a procedure.
If declaration gets out of context then maybe a further splitting of procedure is needed...
Re: Shouldn't this trigger a compiler error?
Posted: Wed Nov 11, 2015 10:10 am
by mariosk8s
The issue is not whether the variable is defined or not, but rather whether it is in the expected state.
The problem with this is that it leads to potentially hard to find runtime bugs.
One could argue that it is the programmers fault. I agree. Programmers do screw things up.
That is why one of the jobs of a compiler is lexical validation followed by translation.
This issue clearly falls under lexical validation.
I realize that PB has limited scope support, that's why this would be a feature request.
It would prevent unnecessary runtime bugs.
After all that is the primary reason for EnableExplicit, isn't it?