That sure seems like a bug to me.
The problem is that when the while loop first evaluates x, x is in fact undefined. Crazy, I know... I'll discuss that below. But if you accept this, then the results make sense:
With x undefined, x>0 is the same as undefined>0, which is false. Hence we don't get to the body of the while loop. With x undefined, x!=0 is true, and so you DO get to the body of the while loop.
You can see these comparisons to 0 in the Test Console in Pencil Code
undefined==0falseundefined!=0trueundefined>0falseundefined<0false
This snippet likewise confirms that x is undefined in the y loop:
x = 1
while (see typeof x) or x > 0 # prints undefined to console
Of course, it sure seems nutty that x is undefined, given that you just declared and initialized it prior to the loop. This has something to do with how CoffeeScript variables are declared and initialized. In general, Coffeescript declares all variables at the top of the program (this is why we don't need to declare them, we just use them. I.e., in JS, you have var x = 1; but in coffee, just x=1). Your script, for example, compiles to the following JavaScript:
(function() {
var x;
x = 1;
while (x > 0) {
await(read('?', defer(x)));
}
}).call(this);
OK, now consider the following variation of your script, which passes y to defer.
await read '?', defer y
x = y
First of all, this script works just fine. But check out what happens when it is compiled to JS (below): we never see how/when y is declared. Now, that may just be because the online compiler I'm using isn't importing iced coffeescript. But it does indicate that in your code the variable x that you reference at the top of your script gets declared but for some reason it gets reset to undefined by the code in the await block. This happens within the while loop, so it affects the condition. (Why? I dunno. This is as far as I can take it at this point!)
(function() {
var x;
x = 1;
while (x > 0) {
await(read('?', defer(y)));
x = y;
}
}).call(this);