4 ms·

Thoughts. This looks to make Javascript even more "lisp-ish" than it already was, by simplifying syntax. Albeit a binary lisp. Second thought - regular zip c

Thoughts. This looks to make Javascript even more "lisp-ish" than it already was, by simplifying syntax. Albeit a binary lisp. Second thought - regular zip compression already minimises Javascript, doesn't it? Which leads to my third thought - isn't the most important problem they are trying to solve, the slow parsing speed of Javascript text? They solve that by introducing unambiguous operators and other things. This could be done without resorting to binary encodings. They could introduce a plain text encoding, where (for instance) only UTF8 is allowed, with unambiguous operators. THEN they could put a binary encoding on top of that, if necessary. Or just zip it. Instead they jumped straight at the binary representation. I'm not saying it's wrong to do so. But maybe unnecessary? Please let me know if my 5 minute understanding of what they are doing is wrong... EDIT: spelling.

Yoric 9y ago
Slow parsing speed is due to several things: - encoding issues; - ambiguous stuff (for instance, `/` can be the start of a comment, the start of a regexp or a division, `()` or `{}` can have several meanings, etc.); - odd behavior (variables can be used before they are declared, double-declaring variables is sometimes valid but not always, etc.); - plenty of information that is necessary for execution is only available after you need it (sometimes much later, e.g. determining free variables, determining whether `eval` can affect local variables, etc). Also, this syntax makes it impossible to perform concurrent parsing (at least not without extremely costly non-concurrent pre-parsing) and makes it basically impossible to perform lazy parsing (at least not without this same extremely costly pre-parsing). If I understand correctly, your suggestion would have been to: 1. provide a "better" developer-facing text syntax; 2. if necessary, move to binary parsing. Your suggestion makes sense but I believe that it underestimates seriously the ability to: a. come up with an alternative, easier to parse, text syntax; b. make sure that your text syntax has the same semantics as the original syntax; c. get everybody to agree on that text syntax; d. maintain this text syntax through successive versions of JavaScript, without losing its desirable properties; e. have every browser maintain two text parsers. Also, note that b. most likely means standardizing upon an AST, which is roughly half of the difficulty of the current proposal. Finally, unless I am missing something, your suggestion does not improve concurrent or lazy parsing. One of the core benchmarks behind the current proposal is that lazy parsing can be made extremely faster than non-lazy parsing, as soon as you the expensive pre-parsing phase has been abolished. Does this answer your questions?

Yoric 9y ago

Slow parsing speed is due to several things: - encoding issues; - ambiguous stuff (for instance, `/` can be the start of a comment, the start of a regexp or a division, `()` or `{}` can have several meanings, etc.); - odd behavior (variables can be used before they are declared, double-declaring variables is sometimes valid but not always, etc.); - plenty of information that is necessary for execution is only available after you need it (sometimes much later, e.g. determining free variables, determining whether `eval` can affect local variables, etc). Also, this syntax makes it impossible to perform concurrent parsing (at least not without extremely costly non-concurrent pre-parsing) and makes it basically impossible to perform lazy parsing (at least not without this same extremely costly pre-parsing). If I understand correctly, your suggestion would have been to: 1. provide a "better" developer-facing text syntax; 2. if necessary, move to binary parsing. Your suggestion makes sense but I believe that it underestimates seriously the ability to: a. come up with an alternative, easier to parse, text syntax; b. make sure that your text syntax has the same semantics as the original syntax; c. get everybody to agree on that text syntax; d. maintain this text syntax through successive versions of JavaScript, without losing its desirable properties; e. have every browser maintain two text parsers. Also, note that b. most likely means standardizing upon an AST, which is roughly half of the difficulty of the current proposal. Finally, unless I am missing something, your suggestion does not improve concurrent or lazy parsing. One of the core benchmarks behind the current proposal is that lazy parsing can be made extremely faster than non-lazy parsing, as soon as you the expensive pre-parsing phase has been abolished. Does this answer your questions?