| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <title>Ingekleed vraagstuk: dakdekkerslift huren en plaatsen</title> | |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> | |
| <meta http-equiv="X-UA-Compatible" content="IE=edge" /> | |
| <meta name="viewport" content="width=device-width, initial-scale=1"> | |
| <link rel="stylesheet" href="bootstrap4/css/bootstrap.css"> |
This is a list of guidelines to make your Javascript faster, often associated with jsPerf benchmarks.
If you have an existing codebase, don't get carried away with premature optimizations. Profile to find the slow bits and pick the low hanging fruit.
Note: I'm not native English speaking and don't have the natural language processing jargon down pat, so the 'preceeding' vs. 'proceeding' I assume the PREceeding text before 'x' in 'zzxz' is the leading 'zz' ('history') and the PROceeding text for the same is the trailing 'z', hence 'proceeding text' would be similar to 'look ahead' as it is called in computer language parsing (unambiguous language parsing).
Anyway... I'm sure I don't get everything you say but there's at least one subject which is certainly relevant here:
In your sample grammar and sample 'zzxz' I assume each character is a single token. (Yes, PEG always processes characters as it blends lexer and parser into a single specification language; I'm just sufficiently dinosaur to appreciate the difference between 'character stream' and 'token stream': the token stream is where such nice horrors as left recursion are to be ex
xxx
This code is a stripped version of actual production code which employs this JISON clone:
(https://github.com/GerHobbelt/jison)
hence make sure to diff that one against vanilla to see differences/features.
code shows .yy.parseError, lexer.post_lex, parser.post_parser, how to get
the token identifier strings from the JISON-generated parser class, etc.
| // Use Gists to store code you would like to remember later on | |
| console.log(window); // log the "window" object to the console |
| %options ranges | |
| %options backtrack_lexer | |
| /* | |
| * lexical grammar | |
| * =============== | |
| * | |
| * This section defines the lexer rules for our formula parser. The rules are checked from top to bottom, so order is import | |
| * here! | |
| * |
| *.sh text eol=lf | |
| *.php text eol=lf | |
| *.inc text eol=lf | |
| *.html text eol=lf | |
| *.js text eol=lf | |
| *.css text eol=lf | |
| *.ini text eol=lf | |
| *.txt text eol=lf | |
| *.xml text eol=lf | |
| *.md text eol=lf |
Lexers, Parsers, Code Generators are of all ages (old skool: lex/flex, yacc/bison (modern-ish: PCCTS/ANTLR), burg/lburg/...)
Here's an example of a JavaScript based domain-specific language being parsed and converted into HTML. It is very similar to wiki and MarkDown formats; the only purpose of this code is to showcase the parsing technology, so a minimum number of 'shortcuts' and other production code 'smartness' is applied.
The recursive descent parser works by evaluating the grammar rules in order of precedence, where each function call is a grammar rule match attempt and the first one returning success is a 'grammar rule match' which will allow the parser to continue parsing the input.
Also, the input is assumed to be size limited, i.e. a infinite lookahead grammar is fine with us. (This doesn't work in situations where you need to parse a stream, but that is a problem area that few of us have to deal with in actual reality. Mostly we like limited lookahead grammars becaus