Quit reusing temporary variables

[satyr]

Pros

• May run faster on modern type-analysing engines.
• Less boilerplate in compiler.

Cons

• Uglier compilation.

E.g.:

$ coco -bce 'a < f() < g() < b'
var ref$;
a < (ref$ = f()) && ref$ < (ref$ = g()) && ref$ < b;

would go back similar to:

$ coffee -bce 'a < f() < g() < b'
// Generated by CoffeeScript 1.4.0
var _ref, _ref1;

((a < (_ref1 = f()) && _ref1 < (_ref = g())) && _ref < b);

[vendethiel]

• Uglier compilation.

I don't think that's really true. The varlist will be at the top on one line, so for this it doesn't matter, and ref or ref1 doesn't change much to my eyes

[satyr]

The longer the list the more it hurts eyes, especially when your editor wraps lines.

E.g. test/literal.co compilation would go from:

var i, ref$, a, b, obj, array, x, y, one, two, zero, n, m, count, list, key$, b
ase, c, num, share, e, fn, o, f, q, O, ref1$, u, ref2$, ref3$, x0$, res$, i$, l
en$, x1$, x2$, funs, x3$, x4$, this$ = this, toString$ = {}.toString, slice$ = 
[].slice, join$ = [].join, replace$ = ''.replace, split$ = ''.split;

to:

var i, ref$, a, b, obj, ref1$, array, ref2$, ref3$, ref4$, x, y, one, two, zero
, n, m, count, list, key$, key1$, key2$, base, ref5$, ref6$, ref7$, c, num, sha
re, ref8$, e, fn, o, ref9$, ref10$, ref11$, ref12$, ref13$, f, ref14$, q, O, re
f15$, key3$, ref16$, key4$, u, ref17$, ref18$, ref19$, ref20$, ref21$, ref22$, 
ref23$, ref24$, ref25$, ref26$, ref27$, ref28$, ref29$, ref30$, ref31$, ref32$,
 ref33$, x0$, res$, i$, len$, x1$, x2$, funs, x3$, x4$, ref34$, ref35$, ref36$,
 ref37$, ref38$, ref39$, ref40$, this$ = this, toString$ = {}.toString, slice$ 
= [].slice, join$ = [].join, replace$ = ''.replace, split$ = ''.split;

Though yes, it's only about the length of var lines and variable names.

[vendethiel]

var eR, ref$, a, sum, i$, len$, n, result, o, points, I2, e, moe, obj, config, key, pick, t, i, ref1$, b, show, til, x$, y$, z$, z1$, slice$ = [].slice, join$ = [].join; for me.
I don't really care about variable declarations in my compiled files - if I need to open one to debug, that's not gonna be a problem anyway, that's not code I read. If that can not only clean up the parser but also may improve speed I'm all for it - is variable declaration ugliness in compiled code an important factor ?

[satyr]

Code size does matter to JS files (for download speed, memory consumption etc.). Hopefully the increase will be negligible.

[vendethiel]

Unless you have a case like this one I don't think it adds much more bytes.

Long version is 623 chars long, short is 305 (and I think it's a rather controversial example since it tests bugs for these meaning many cases)