Inner loop array index bug
I encountered what looks like a bug. In the sample code below, the array indexing in the line with the assignment of x0 causes the following error: [bug597534.ck]:line(22): array subscripts (1) exceeds defined dimension (0) It does not happen when the same kind of construct is used in the top loop, also as in the example code. Hans Aberg ---- Hid kb; HidMsg msg; if(!kb.openKeyboard(0)) me.exit(); <<< "Keyboard '", kb.name(), "' ready." >>>; // Key x-axis coordinate int x[256]; while(true) { kb => now; x[msg.which] => int y; x[msg.which] => int y0; while(kb.recv(msg)) { x[msg.which] => int x; x[msg.which] => int x0; } } ----
I think ChucK can get pretty confused about this line:
x[msg.which] => int x;
...in which x is treated both as an array and as a newly declared integer
variable. I would rename the array to avoid confusion.
/Stefan
On Wed, Apr 22, 2009 at 2:04 PM, Hans Aberg
I encountered what looks like a bug. In the sample code below, the array indexing in the line with the assignment of x0 causes the following error: [bug597534.ck]:line(22): array subscripts (1) exceeds defined dimension (0) It does not happen when the same kind of construct is used in the top loop, also as in the example code.
Hans Aberg
---- Hid kb; HidMsg msg;
if(!kb.openKeyboard(0)) me.exit(); <<< "Keyboard '", kb.name(), "' ready." >>>;
// Key x-axis coordinate int x[256];
while(true) { kb => now;
x[msg.which] => int y; x[msg.which] => int y0;
while(kb.recv(msg)) { x[msg.which] => int x; x[msg.which] => int x0; } } ---- _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Release me, insect, or I will destroy the Cosmos!
Stefan;
I think ChucK can get pretty confused about this line:
x[msg.which] => int x;
...in which x is treated both as an array and as a newly declared integer variable. I would rename the array to avoid confusion.
Yes, I agree. Still, while Hans shouldn't do that to preserve his own and our sanity, I do think ChucK could come up with a better complaint than this; [unnamed1]:line(20): array subscripts (1) exceeds defined dimension (0) With this test code it goes right; int x[2]; int x; And we get a rather appropriate [unnamed1]:line(2): 'x' has already been defined in the same scope... Which leads to the question "what on earth is going on here?" So in the interest of science I performed another experiment; int x[2]; while(1) { //this runs though I seriously wonder whether it should int x; second => now; } So; apparently loops have their own scope, like functions do, yet in this case Hans is trying to use both the "x" from the file's scope (the array) and the "x" of the loop's scope on the same line and ChucK gets all confused. Aside from the factor that we can question whether it's smart to do this kind of thing to the variable names something is going wrong here; either loops have their own sub-namespace or they don't. Unless somebody can explain this to me I'm calling this a bug as well though I don't agree that Hans's code should run. In this case x should be a array (and so no defining a int called x) or it should be a int within the scope of the loop (and so no addressing of the array from within the loop). I'm fine with either choice but I do think a choice should be made. Yours, Kas.
On 22 Apr 2009, at 17:17, Kassen wrote:
I think ChucK can get pretty confused about this line:
x[msg.which] => int x;
...in which x is treated both as an array and as a newly declared integer variable. I would rename the array to avoid confusion. ... I do think ChucK could come up with a better complaint than this;
[unnamed1]:line(20): array subscripts (1) exceeds defined dimension (0)
With this test code it goes right;
int x[2]; int x;
And we get a rather appropriate
[unnamed1]:line(2): 'x' has already been defined in the same scope...
The problem is really that if I remove the second line of: x[msg.which] => int x; x[msg.which] => int x0; then the first x[msg.which] => int x; is accepted. So when I add the second line, I get a confusing error message about that, not about the first one, which seemed a legal name overload (though differing from C++). Hans
Compilers can't always be expected to understand every kind of error, and
that error message isn't the worst I've seen :) Still, if the opportunity os
there to change it to something better, now harm done. The situation can be
translated to this:
int x;
1 => x[1];
which gives the same subscript error message. Hans's code is otherwise
without problems - ChucK allows (like many other languages) to reuse a
variable identifier in a new block, so x can be redeclared as an int in the
inner while loop, overshadowing the outer x which is an array.
/Stefan
On Wed, Apr 22, 2009 at 5:55 PM, Hans Aberg
On 22 Apr 2009, at 17:17, Kassen wrote:
I think ChucK can get pretty confused about this line:
x[msg.which] => int x;
...in which x is treated both as an array and as a newly declared integer variable. I would rename the array to avoid confusion.
... I do think ChucK could come up with a better complaint than this;
[unnamed1]:line(20): array subscripts (1) exceeds defined dimension (0)
With this test code it goes right;
int x[2]; int x;
And we get a rather appropriate
[unnamed1]:line(2): 'x' has already been defined in the same scope...
The problem is really that if I remove the second line of: x[msg.which] => int x; x[msg.which] => int x0; then the first x[msg.which] => int x; is accepted.
So when I add the second line, I get a confusing error message about that, not about the first one, which seemed a legal name overload (though differing from C++).
Hans
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Release me, insect, or I will destroy the Cosmos!
On 22 Apr 2009, at 21:01, Stefan Blixt wrote:
Compilers can't always be expected to understand every kind of error, and that error message isn't the worst I've seen :) Still, if the opportunity os there to change it to something better, now harm done. The situation can be translated to this:
int x; 1 => x[1];
which gives the same subscript error message. Hans's code is otherwise without problems - ChucK allows (like many other languages) to reuse a variable identifier in a new block, so x can be redeclared as an int in the inner while loop, overshadowing the outer x which is an array.
The problem is really that 'chuck' accepts x[msg.which] => int x; Then when a line after that is added x[msg.which] => int x0; it complains about this line, giving that cryptic message, despite the fact that it is correct. When the first line is accepted, that gives the impression that this name overloading is legal, though it differs from C++. Thus I started to use it. Chuck needs to make up its mind: is this name overloading legal or not. If it is not, it should always be rejected. Hans
Aha... I agree that's a bit weird. Perhaps lines like these:
y => int z;
are seen as an initialization of z, where y can be taken from the outer
scope, and not treated the same as
int z;
y=> z;
/Stefan
On Wed, Apr 22, 2009 at 10:19 PM, Hans Aberg
On 22 Apr 2009, at 21:01, Stefan Blixt wrote:
Compilers can't always be expected to understand every kind of error, and
that error message isn't the worst I've seen :) Still, if the opportunity os there to change it to something better, now harm done. The situation can be translated to this:
int x; 1 => x[1];
which gives the same subscript error message. Hans's code is otherwise without problems - ChucK allows (like many other languages) to reuse a variable identifier in a new block, so x can be redeclared as an int in the inner while loop, overshadowing the outer x which is an array.
The problem is really that 'chuck' accepts x[msg.which] => int x; Then when a line after that is added x[msg.which] => int x0; it complains about this line, giving that cryptic message, despite the fact that it is correct.
When the first line is accepted, that gives the impression that this name overloading is legal, though it differs from C++. Thus I started to use it.
Chuck needs to make up its mind: is this name overloading legal or not. If it is not, it should always be rejected.
Hans
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Release me, insect, or I will destroy the Cosmos!
On 23 Apr 2009, at 07:42, Stefan Blixt wrote:
Aha... I agree that's a bit weird. Perhaps lines like these:
y => int z;
are seen as an initialization of z, where y can be taken from the outer scope, and not treated the same as
int z; y=> z;
It might be possible. When reading int x[256]; ... while(kb.recv(msg)) { x[msg.which] => int x; x[msg.which] => int x0; } the first definition in the inner environment defines a new "x". Then, on the next definition, that x is used, because it covers the global "x". So, since it is not an array, one gets the index error. Hans
Stefan;
Aha... I agree that's a bit weird. Perhaps lines like these: y => int z; are seen as an initialization of z, where y can be taken from the outer scope, and not treated the same as int z; y=> z; /Stefan
Could you explain what exactly you feel the difference might be? I don't see what you are refering to here. Yours, Kas.
Well, it's all uncertain speculation, but in Java, where you have places in
the code what may not contain code other than variable declarations, you can
write stuff like this:
int x = 2;
which can be handled by the compiler with special optimization. I think Java
also handles declarations and assignements specially when use in a block
(like a method or loop). I was wondering if there may be a similar
optimization in ChucK, which is obscured by the fact that you can mix code
and declarations everywhere.
I don't have a ChucK compiler where I am now, otherwise I would have done
some experiments.
/Stefan
On Thu, Apr 23, 2009 at 10:59 AM, Kassen
Stefan;
Aha... I agree that's a bit weird. Perhaps lines like these: y => int z; are seen as an initialization of z, where y can be taken from the outer scope, and not treated the same as int z; y=> z; /Stefan
Could you explain what exactly you feel the difference might be? I don't see what you are refering to here.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Release me, insect, or I will destroy the Cosmos!
On 22 Apr 2009, at 16:18, Stefan Blixt wrote:
I think ChucK can get pretty confused about this line:
x[msg.which] => int x;
...in which x is treated both as an array and as a newly declared integer variable. I would rename the array to avoid confusion.
That was indeed the problem. Thank you. ChucK accepts that name overload in some situations, so I started to use it, though it differs from C/C++. Hans
participants (3)
-
Hans Aberg -
Kassen -
Stefan Blixt