Re: [chuck-users] time and truth (bug?)

On Thu, Jul 24, 2008 at 3:00 PM, Kassen wrote:

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 *was* kind of curious how you came up with this case.. ;-) 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. 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. 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. Steve