++ -- operations bug

[kaievns]

Hi,

It seems there is a bit of an issue with the ++ and -- operations when there is a space between a variable and the operation

smth++  # works
smth ++ # doesn't

Probably both versions should be supported

Cheers

[TrevorBurnham]

CoffeeScript is stricter about whitespace between operators and operands than JavaScript is; this is the price of implicit parentheses. How, for instance, would you interpret

a ++ b

? It could either be a syntax error, or a(++b). If the latter, then wouldn't it be a bit odd for a ++ to mean a++?

Similarly, a frequent complaint that f +a and f + a have different meanings. Again, it's just the price of implicit parentheses; they imply certain stylistic limitations.

[satyr]

a ++; is clearly postcrement. Reading it as a(++) is kinda dumb.

How, for instance, would you interpret

a ++ b

?

The same rule as +/- can apply.

[kaievns]

Hi Trevor,

Good point. afaik they don't have ++ in ruby for the same reason. But, maybe it could be handled at least in those cases where it's pretty much clear what's going on, kinda like that

method i++, something
method ++i # nothing

If it's not too much of a trouble

[TrevorBurnham]

@satyr When you say of a ++ b that

The same rule as +/- can apply

what do you mean? Are you saying that a ++ b should compile to a ++ b?

[satyr]

what do you mean? Are you saying that a ++ b should compile to a ++ b?

The same rule we use to enable a +b => a(+b) (check if the operator is spaced from the following token).
a ++ b would be read as (a++) b and cause syntax error.

[michaelficarra]

@satyr:

a+ b -> a + b
a +b -> a(+b)
a + b -> a + b
a++ b -> currently syntax error, should be (a++)(b)
a ++b -> a(++b)
a ++ b -> ? (currently a(++b))

That last one does not have an obvious compilation. Both (a++)(b) and a(++b) appear valid to me, though a(++b) would almost certainly be the most commonly desired compilation. a ++ b (javascript) would not be a good compilation.

[satyr]

Both (a++)(b) and a(++b) appear valid to me

The former doesn't make sense as a++ clearly isn't callable.

[michaelficarra]

a++ clearly isn't callable.

That's not necessarily true. It's valid ECMAScript that will almost always throw a runtime error.

If a JS parser will parse it, we should be allowed to output it. There's no reason we should be able to write (a++) b and not a++ b. So that leaves a ++ b as ambiguous.

[satyr]

almost always

You mean, you know a case that a++ returns a callable object?

If a JS parser will parse it, we should be allowed to output it

Allowing expressions that will only cause runtime errors benefits nobody. Accepting things like f() = x is a bad part of JS. We should try to reject them.
In fact, our = don't allow f() to the left, and our list of tokens for implicit call (CALLABLE in lexer) don't include ++/--.

[michaelficarra]

No, I only meant to say that it was possible. You've given a convincing argument, though, and I now agree that compiling to a(++b) would be a perfectly reasonable assumption to make.