Open taralx opened 11 years ago
This can also be a performance issue if we end up holding onto large temporaries.
Is there any example of coffee-script doing this kind of optimization with static code analysis anywhere else? Once you do this you are opening up a can of worms.
On Sat, Feb 16, 2013 at 12:03 PM, taralx notifications@github.com wrote:
This can also be a performance issue if we end up holding onto large temporaries.
— Reply to this email directly or view it on GitHubhttps://github.com/maxtaco/coffee-script/issues/60#issuecomment-13672204.
Absolutely. Look at the difference between "loop 1" and "a = loop 1" in the coffeescript output.
I don't know if there are other examples but that is not an optimization. It is different coffeescript compiling to different javascript. Static analysis is required to know if a loop is used or not.
On Sat, Feb 16, 2013 at 2:14 PM, taralx notifications@github.com wrote:
Absolutely. Look at the difference between "loop 1" and "a = loop 1" in the coffeescript output.
— Reply to this email directly or view it on GitHubhttps://github.com/maxtaco/coffee-script/issues/60#issuecomment-13675994.
Indeed, and I am asking for different code generation. Let me try another example:
->
while a
a = f()
and
->
while a
a = f()
14
produce different code. I'd like the same thing for ics:
->
while a
await f defer a
vs
->
while a
await f defer a
14
could produce different code the same way, yes?
Thanks for the comments @taralx . The current implementation is still attempting to treat awaited statements as expressions, but I want to kill that feature. That basket of (very hairy features) was only added to appease the CoffeeScript crowd who wound up rejecting the Iced patch anyways.
However, I'm waiting on the CoffeeScriptRedux rewrite before I make any big changes to Iced.
Thanks for the kind words @maxtaco. However, I respectfully disagree that awaited expressions are the blocking issue here: even if await isn't an expression, you still have this problem. For example:
while a
await f defer a
1
1
should not build a _results array, but does anyway.
That still is an awaited expressed implementation-wise, since the while block needs to undergo a full AST rotation.
In while loops, it would be nice we could skip construction of the _results array (and the associated _next function) if the loop results aren't used. This code isn't optimized away by closure. :/