adding minify option

[Constellation]

I suggest adding minify option to code generator.

from http://code.google.com/p/esprima/issues/detail?id=186

[Constellation]

• not adding unnecessary new lines
• not adding indent
• not adding unnecessary spaces (1 + 1 => 1+1)
  • of course, necessary spaces are required (delete i)

[Constellation]

NOTE.

Taking care of some operator's concatnation.

for example, 1 + (+1) should be 1+ +1, not 1++1

[RGustBardon]

This is the objective of https://github.com/reduce/escodegen

[Constellation]

Great!
It's very interesting. Do you have a plan merging it to mainline?

[RGustBardon]

@Constellation: Thank you for your reply and the tweet. It would be great if the changes could make it to the mainline. As yet, unit tests are missing.

1. Was \v left out of escapeString due to it not being supported by JSON? If so, why are single quotes used as delimiters?
2. Could double quotes be used as default delimiters?
3. Why is DELETE (U+007F) not escaped?
4. Could the software throw an exception if the value of a literal is a negative number, a negative zero, or a NaN value?
5. For each of the following substitutions, would it be acceptable for them to be default? Should a corresponding formatting option exist for any of them?
   1. "\u0000" as "\0" and "\u00001" as "\x001".
   2. "\u000b" as "\v".
   3. "\u0080" as "\x80".
   4. 1e309 as 1e400.
   5. 1.7976931348623157e+308 as 1.7976931348623157e308.
   6. 4.2e+101 as 42e100.
   7. 1000000000001 as 0xe8d4a51001.
   8. 42000 as 42e3.
   9. 0.42 as .42.
   10. 4.2e-99 as 42e-100.
   11. /\u0000/ as /\0/ and /\u00001 as /\x001/.
   12. /\u0001/ as /\ca/, /\u0002/ as /\cb/, /\u0003/ as /\cc/, /\u0004/ as /\cd/, /\u0005/ as /\ce/, /\u0006/ as /\cf/, /\u0007/ as /\cg/, /\u0008/ as /\ch/, /\u000e/ as /\cn/, /\u000f/ as /\co/, /\u0010/ as /\cp/, /\u0011/ as /\cq/, /\u0012/ as /\cr/, /\u0013/ as /\cs/, /\u0014/ as /\ct/, /\u0015/ as /\cu/, /\u0016/ as /\cv/, /\u0017/ as /\cw/, /\u0018/ as /\cx/, /\u0019/ as /\cy/, and /\u001a/ as /\cz/.
   13. /\u0009/ as /\t/, /\u000a/ as /\n/, /\u000b/ as /\v/, /\u000c/ as /\f/, and /\u000d/ as /\r/.
   14. /\u001b/ as /\x1b/, /\u001c/ as /\x1c/, /\u001d/ as /\x1d/, /\u001e/ as /\x1e/, and /\u001f/ as /\x1f/.
   15. /\u0061/ as /a/.
   16. /\u007f/ as /\x7f/.
   17. /\u010A/ as /\u010a/.
   18. /[\u0000-\uffff]/ as /[\s\S]/.
   19. /[\u0008]/ as /[\b]/.
   20. /[aabuxz]/ as /[abuxz]/.
   21. /[abcdefg]/ as /[a-g]/.
   22. /[a-z]|[A-Z]|[0-9]|_/ as /\w/.

[Constellation]

Thank you for your reply, great contribution and clarification!!

1. Yes, JSONString is subset of ECMAScript StringLiteral. In the meantime we took this type.
2. Because I took the esprima project coding style for generated code.
3. Because JSONString / ECMAScript StringLiteral can accept it. I took JSONString stringify strategy.
4. This is very reasonable. I agree to this change. Throwing exception is more descriptive.

And I answer the last.

1. String conversion
   • I think making your form default is better :)
   • Adding new format option that indicates JSON compatible string is good.
2. Number conversion
   • Personally I think Number#toString result is good to view code.
   • So I think minifying numeric literals when minifying option is provided is better.
3. RegExp conversion
   • Because /\u0000/.source is different from /\0/.source... I think we should use RegExp#toString simply.
   • I think that escodegen should not change meaning of AST. If we require compressing RegExp (that source is not compatible to original code), we prepare new pass to modify AST and pass AST to escodegen. This is out of escodegen's work.
     • esprima -> compressing pass -> escodegen
     • Prepareing compressing pass function (like exports.compressRegExp(AST) -> AST function) and using it is better like this.

  var ast = esprima.parse(code);
  ast = escodegen.compressRegExp(ast);
  var result = escodegen.generate(ast);

Do you think about these answers?

[RGustBardon]

If escaping is modeled after JSON.stringify, why is every character from U+0080 onward escaped?
Now, therefore, should U+007F be escaped by default? Assuming a JSON option would exist and it would be disabled by a user, should everything not in the range from SPACE (U+0020) until TILDE (U+007E) be escaped?

No characters shall be additionally escaped in regular expression literals. Therefore

echo -e 'print(escodegen.generate(esprima.parse("/\x01/;")));' > /tmp/foo
v8 esprima.js escodegen.js /tmp/foo

shall yield the sequence U+002F U+0001 U+002F U+003B.

With regard to the JSON option:

• QUOTATION MARK (U+0022) must used as a delimiter.
• SOLIDUS (U+002F) must be escaped. \/ would do.
• \v is not allowed. \u000b must be used instead.
• \xNN is not allowed. \u00NN would have to be used if a shorter escape sequence is unavailable.
• LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) would be allowed. Perhaps it would be better to escape them nonetheless.
• 1e309, 1000000000001, and 0.42 must be preserved. When it comes to 1e309, raw is required.

Would a Boolean reduce formatting option be better than:

• String newline (the string to be inserted before the first statement of a block etc.; default: '\n'),
• String space (the string to be inserted after the comma operator etc.; default: ' '),
• Boolean semicolons (i.e. whether semicolons at the end of a block and a program should be preserved; default: true),
• String delimiter (i.e. the string to be used as a delimiter for string literals; if empty, choose the delimiter that yields a more concise string literal; default: '\''),
• Boolean escapeless (i.e. escape as few characters as possible; default: false), and
• Boolean renumber (i.e. represent 42000 as 42e3 etc.; default: false)?

Would a single patch be preferred over several smaller ones?

[Constellation]

Thanks for your clarification!

If escaping is modeled after JSON.stringify, why is every character from U+0080 onward escaped?

I escaped non-ASCII characters.
But to make JSON.stringify behavior precisely, this is not suitable.
Yes, we should replace this to more considered one.

No characters shall be additionally escaped in regular expression literals. Therefore...

I agree to this.

With regard to the JSON option:
LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) would be allowed. Perhaps it would be better to escape them nonetheless.

Yes, JSON stringifier with \u2028 / \u2029 is good for the JSON option. This clarification is perfect :-)

Would a Boolean reduce formatting option be better than:

Personally, I prefer detailed options to control formats. Do you think about this?

Would a single patch be preferred over several smaller ones?

I prefer smaller ones.
And when creating pull requests, please add your name to copyright lines in top comment :-)

[michaelficarra]

I really don't understand this effort. What is the purpose of putting out code that is formatted succinctly, but hasn't been optimised through any series of transformations?

[RGustBardon]

As stated in this issue, such transformations are outside the scope of escodegen.

The rationale behind this effort is that there is a nascent project dedicated to transforming an abstract semantic graph in order to rewrite programs written in ECMAScript so that they can be represented using as few Unicode code points as possible. That project is reduce-core.

Since an ECMAScript parser (i.e. Esprima) is readily available, there is no need to write a new one for the reduction system. When it comes to an ECMAScript code generator, all that was needed was to submit a few patches to escodegen.

[michaelficarra]

Ah, very nice. Finally, a minifier done right. If you want, feel free to take some influence from the optimiser in my CoffeeScript compiler. Try to keep the reductions as declarative as possible. Good luck!