Euphoria
Ticket #576:
scope of block variable incorrect
-
Reported by
coconut
Dec 29, 2010
enum a,b
while 1 do
integer b -- the scope of this variable should be limited to the while
b=1
?b
exit
end while
Running this report a bug saying that b is already declared. This is incorrect as the scope integer b is limited to while block.
Details
1. Comment by jeremy
Dec 30, 2010
The variable is defined twice. You have enum a, b and also integer b. That is invalid.
2. Comment by jimcbrown
Dec 30, 2010
One can argue that there is an inconsistency here.
E.g.
integer a
for i = 1 to 5 do
integer b = 20
end for
? b
Gives an error about b not being defined or something.
While this:
integer a
for i = 1 to 5 do
integer b = 20
end for
integer b = 9
? b
Works, in spite of b being defined twice.
If it's ok to define b twice in that example, why is it an error to define b twice in the original example in this ticket? There had better be a very good justification for this in order for this not to be considered a bug, and this sort of behavior can be very confusing to even those of us who have been initiated into the very deep dark depths of Euphoria's internal workings...
3. Comment by mattlewis
Dec 30, 2010
While the message isn't wrong, euphoria makes the assumption that you can only override names at the same levels before, not at smaller scope levels. As Jacques said on the forum, however, other languages do this differently, and perhaps euphoria should, too.
The following is valid C:
#include <stdio.h>
int main(){
int b;
b = 0;
printf("b: %d\n", b);
while(1){
long b = 5;
printf("b: %ld\n", b);
break;
}
printf("b: %d\n", b);
return 0;
}
$ gcc scope.c && ./a.out
b: 0
b: 5
b: 0
4. Comment by jeremy
Dec 30, 2010
In your example Jim, it's not defined twice. That's exactly where scoping comes into play. integer b is defined inside of the for block. Its definition exists only inside of the for block. Then later, outside of the for block you define a variable b. It has nothing to do with your b that is defined inside of the for block. They are two different scopes.
Now, in the first example:
integer b = 1
for .... do
integer b
In that case, b is defined in the outer scope and inside of the for scope. The for scope has its own scope as well as shares its parents scopes. Thus, b is defined multiple times.
5. Comment by jeremy
Dec 30, 2010
If it should be done differently, it should become a feature request, not a bug report. I personally like the simplicity of how Euphoria does it now. I think your example is bad programming practice having the same variable name be multiple types w/in a given logical block of code. What would be a valid use for this?
6. Comment by jimcbrown
Dec 30, 2010
Ok, well, I understand why in technical terms
integer b
for ...
integer b
end for
is considered bad, while
for ...
integer b
end for
integer b
works ok.
However, I can also see why a new user can be confused by the concept of the for loop sharing scope with the parent scope (or at least identifier declarations).
Not a bug, but a feature request that needs to be done ASAP because it's very newbie unfriendly?
7. Comment by jeremy
Dec 30, 2010
I don't see where it is newbie unfriendly either. I thought it was just natural?
8. Comment by jimcbrown
Dec 30, 2010
To me it's very unnatural. The scoping rules are very inconsistent. But that's coming from a C background.
9. Comment by jeremy
Dec 30, 2010
Your example really isn't scoping is it? Its redefinition and we do not allow redefinition.
10. Comment by jimcbrown
Dec 30, 2010
This isn't redefinition?
for ...
integer b
end for
integer b
Granted, we do allow redefinition in some limited cases.
integer b
procedure x()
integer b
end procedure
works. And this also works.
procedure x()
integer b
end procedure
integer b
I think there's a pattern here...
11. Comment by mattlewis
Dec 30, 2010
It depends on how you look at it, and which boundaries you allow this sort of behavior. Currently, we allow multiple names for symbols in different files, and for symbols at top level and inside a routine. However, those were the only scoping boundaries we had prior to 4.0.
Since we added another level, it probably makes sense that it's a real scope boundary, just like the boundary between top level and a routine.
GitHub