2008/7/24 Stephen Sinclair :

Agreed. The && operator does an implicit cast to boolean values, so it should work, since it shouldn't actually be comparing int and time, but comparing two booleans which have been derived from int and time. I'd say its a bug.

Yes, that's how I look at it as well. Behind the scenes, BTW, it turns out "true" is treated as a integer (we don't have booleans at all), at least according to the error messages but that doesn't matter much. Stefan is right that we can't go casting anything into anything, but we're not; we are evaluating the value for being non-zero, which is different and in fact has been shown to work already for single clauses. I ran into it, BTW, stuffing a command (storing now, which itself returns "now" of type "time") into the condition of a "if" clause to make sure it only ran if the first check was valid yet regardless of the third and last condition. You can wonder whether that's good practice but I was four or five tabs deep already and this (would have) saved an extra one. With the improvement to if-clause parsing of two or so versions ago this has become more important since using multiple clauses is more powerful now.... but I can definitely see how this was previously overlooked. I'll add it to the Wiki as a bug, if Ge disagrees we can remove it again but right now I say "bug". Yours, Kas.

2008/7/24 Stephen Sinclair :

I *was* kind of curious how you came up with this case.. ;-)

:¬) I'd explain more but it's a part of a interface revision of a 2500 or so line file so that would quickly get complicated and require a lot of explaining.... Of course anything that would run into this can also be re-written.

I wonder if it wouldn't be better to have the compile issue an error on something like if(second), since I don't see how it's very useful and could lead to bad logic on the part of the user.

Well, it's convenient for things like this; while (beat => now) { my_drum(boom); } ...which is arguably bad form but very pleasant to write. I forgot who came up with it but it's popular in the "one line ChucK crazy" game on the forum.

if(!now) could be useful for doing something only when the VM first starts up, however I generally think that basing your scripts on absolute time (relative to start of VM) is probably bad practice. Not to mention that if(!now), while nice and compact, is not the most readable way to express that logic.

It's also invalid because "now" is not a integer and you can only do "not" on integers. If you want that you will have to go; if ( !((now / samp) $ int) ) <<<"yay">>>; First the division creates a float, we cast that to integer and this int can be inverted logically. That is, BTW, a issue with inversion, not with evaluating if clauses as such. I use that sort of thing too toggle Gain's used as routing gates; Gain g; //toggle !( g.gain() $ int) => g.gain; Ok, well, maybe it's a similar kind of case... after all. Perhaps "!" simply should return "1" for non-zero inputs. Beware, BTW, that the above examples aren't without danger because you can have rounding errors casting to int. I think casting to int will always round towards 0.

On second though, if(dur) could have some uses, I guess. Not sure. Perhaps in calculating a delay length, while trying to avoid zero-delay feedback.

There I's use; if (delay > 0::ms) Because of the dengers of negative delay. While going over Ge's paper, BTW, I sugested that we could perhaps use "unless" as a miror of "if" since we already have "while" and "untill" which are also mirror.images. I intended this as fun syntactic sugar (like "untill" already is) but now that I think of it; that would nicely get around logic inversion of time and dur type variables in many cases. Interesting discussion; once more it's more complicated then I realised at first. Yours, Kas.