[chuck-users] Inner loop array index bug

Kassen signal.automatique at gmail.com
Wed Apr 22 11:17:42 EDT 2009


> 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];

//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.


More information about the chuck-users mailing list