[chuck-dev] for loop, empty conditional statement, possible fix

[Ge Wang]

Hi Szilveszter and Kassen!

Thanks for the discussion, and thanks to Szilveszter for the report and 
the fix (it's right on)!  I've included the fix into the source, with a 
minor tweak - I think for now, we are going to disallow empty for 
conditions, and will require an explicit true.  For example:

for( ; ; )
{ /*...*/ }

now gets the follow compiler error:

[foo.ck]:line(1): empty for loop condition...
[foo.ck]:line(1): ...(note: explicitly use 'true' if it's the intent)
[foo.ck]:line(1): ...(e.g., 'for( ; true; ){ /*...*/ }')

This will still leave the possibility of for( ; ; ) to work in the 
future, but it seems harder going the other way...

I hope this helps and thanks again for the fix!

All the best,
Ge!

~~~
Ge Wang
Assistant Professor
Center for Computer Research in Music and Acoustics (CCRMA)
Stanford University
http://ccrma.stanford.edu/~ge/
~
Co-founder, CTO, Chief Creative Officer
Smule
http://www.smule.com/ | http://twitter.com/gewang
~~~

On Fri, 23 Oct 2009, Kassen wrote:

> Szilveszter
> 
>
>       I would not go scientific here... :) I just wrote down a line of
>       code which I expected to work... However, I've  never written
>       down anything like:
>
>       if() {} or while() {}
> 
> Erm, no. :-)
>  
>       which I suspect would give a C compiler error.
> 
> I should hope so, yes. If I were a parser I'd go on strike over that.
>  
>       My point is that the first and the third part of the for()
>       statement can be omitted as for now (in ChucK). So I don't see a
>       point why the second one shouldn't work the same way.
> 
> 
> The one perspective I could see is that the first and third are actions, and
> omiting those seems quite natural if we need no action to be taken. The
> second is a condition and it's less intuitively clear what omiting it should
> mean. Borrowing from C seems quite natural.
> 
> I seem to remember there were previous issues with more exotic "for" loops
> in ChucK, btw. Previously there was a issue with stuffing more than one
> thing (some of which could be commands that need not evaluate to true or
> false, as long as the last one did), that would also crash. My memory is
> hazy on this as I didn't see the use but now I do, it's probably to get
> those out of the scope of any "continue" commands we might use.
> 
> Most important to me is that I don't think that anything that comes through
> the parser should crash the whole VM. To be perfectly clear; I don't
> disagree with anything here, I'm just trying to see whether this is or
> should be part of a larger structure that I should understand. I know I can
> sometimes come across like I'm arguing when doing that. I think that urge is
> satisfied for now :-).
> 
> Thanks again,
> Kas.
> 
> 
> 
>