Important: This documentation covers Yarn 1 (Classic).
For Yarn 2+ docs and migration guide, see yarnpkg.com.

Package detail

pegjs

pegjs1mMIT0.10.0TypeScript support: definitely-typed

Parser generator for JavaScript

parser generator, PEG

readme

Build status npm version Bower version License

PEG.js

PEG.js is a simple parser generator for JavaScript that produces fast parsers with excellent error reporting. You can use it to process complex data or computer languages and build transformers, interpreters, compilers and other tools easily.

Features

  • Simple and expressive grammar syntax
  • Integrates both lexical and syntactical analysis
  • Parsers have excellent error reporting out of the box
  • Based on parsing expression grammar formalism — more powerful than traditional LL(k*) and LR(k*) parsers
  • Usable from your browser, from the command line, or via JavaScript API

Getting Started

Online version is the easiest way to generate a parser. Just enter your grammar, try parsing few inputs, and download generated parser code.

Installation

Node.js

To use the pegjs command, install PEG.js globally:

$ npm install -g pegjs

To use the JavaScript API, install PEG.js locally:

$ npm install pegjs

If you need both the pegjs command and the JavaScript API, install PEG.js both ways.

Browser

Download the PEG.js library (regular or minified version) or install it using Bower:

$ bower install pegjs

Generating a Parser

PEG.js generates parser from a grammar that describes expected input and can specify what the parser returns (using semantic actions on matched parts of the input). Generated parser itself is a JavaScript object with a simple API.

Command Line

To generate a parser from your grammar, use the pegjs command:

$ pegjs arithmetics.pegjs

This writes parser source code into a file with the same name as the grammar file but with “.js” extension. You can also specify the output file explicitly:

$ pegjs -o arithmetics-parser.js arithmetics.pegjs

If you omit both input and output file, standard input and output are used.

By default, the generated parser is in the Node.js module format. You can override this using the --format option.

You can tweak the generated parser with several options:

  • --allowed-start-rules — comma-separated list of rules the parser will be allowed to start parsing from (default: the first rule in the grammar)
  • --cache — makes the parser cache results, avoiding exponential parsing time in pathological cases but making the parser slower
  • --dependency — makes the parser require a specified dependency (can be specified multiple times)
  • --export-var — name of a global variable into which the parser object is assigned to when no module loader is detected
  • --extra-options — additional options (in JSON format) to pass to peg.generate
  • --extra-options-file — file with additional options (in JSON format) to pass to peg.generate
  • --format — format of the generated parser: amd, commonjs, globals, umd (default: commonjs)
  • --optimize — selects between optimizing the generated parser for parsing speed (speed) or code size (size) (default: speed)
  • --plugin — makes PEG.js use a specified plugin (can be specified multiple times)
  • --trace — makes the parser trace its progress

JavaScript API

In Node.js, require the PEG.js parser generator module:

var peg = require("pegjs");

In browser, include the PEG.js library in your web page or application using the <script> tag. If PEG.js detects an AMD loader, it will define itself as a module, otherwise the API will be available in the peg global object.

To generate a parser, call the peg.generate method and pass your grammar as a parameter:

var parser = peg.generate("start = ('a' / 'b')+");

The method will return generated parser object or its source code as a string (depending on the value of the output option — see below). It will throw an exception if the grammar is invalid. The exception will contain message property with more details about the error.

You can tweak the generated parser by passing a second parameter with an options object to peg.generate. The following options are supported:

  • allowedStartRules — rules the parser will be allowed to start parsing from (default: the first rule in the grammar)
  • cache — if true, makes the parser cache results, avoiding exponential parsing time in pathological cases but making the parser slower (default: false)
  • dependencies — parser dependencies, the value is an object which maps variables used to access the dependencies in the parser to module IDs used to load them; valid only when format is set to "amd", "commonjs", or "umd" (default: {})
  • exportVar — name of a global variable into which the parser object is assigned to when no module loader is detected; valid only when format is set to "globals" or "umd" (default: null)
  • format — format of the genreated parser ("amd", "bare", "commonjs", "globals", or "umd"); valid only when output is set to "source" (default: "bare")
  • optimize— selects between optimizing the generated parser for parsing speed ("speed") or code size ("size") (default: "speed")
  • output — if set to "parser", the method will return generated parser object; if set to "source", it will return parser source code as a string (default: "parser")
  • plugins — plugins to use
  • trace — makes the parser trace its progress (default: false)

Using the Parser

Using the generated parser is simple — just call its parse method and pass an input string as a parameter. The method will return a parse result (the exact value depends on the grammar used to generate the parser) or throw an exception if the input is invalid. The exception will contain location, expected, found, and message properties with more details about the error.

parser.parse("abba"); // returns ["a", "b", "b", "a"]

parser.parse("abcd"); // throws an exception

You can tweak parser behavior by passing a second parameter with an options object to the parse method. The following options are supported:

  • startRule — name of the rule to start parsing from
  • tracer — tracer to use

Parsers can also support their own custom options.

Grammar Syntax and Semantics

The grammar syntax is similar to JavaScript in that it is not line-oriented and ignores whitespace between tokens. You can also use JavaScript-style comments (// ... and /* ... */).

Let's look at example grammar that recognizes simple arithmetic expressions like 2*(3+4). A parser generated from this grammar computes their values.

start
  = additive

additive
  = left:multiplicative "+" right:additive { return left + right; }
  / multiplicative

multiplicative
  = left:primary "*" right:multiplicative { return left * right; }
  / primary

primary
  = integer
  / "(" additive:additive ")" { return additive; }

integer "integer"
  = digits:[0-9]+ { return parseInt(digits.join(""), 10); }

On the top level, the grammar consists of rules (in our example, there are five of them). Each rule has a name (e.g. integer) that identifies the rule, and a parsing expression (e.g. digits:[0-9]+ { return parseInt(digits.join(""), 10); }) that defines a pattern to match against the input text and possibly contains some JavaScript code that determines what happens when the pattern matches successfully. A rule can also contain human-readable name that is used in error messages (in our example, only the integer rule has a human-readable name). The parsing starts at the first rule, which is also called the start rule.

A rule name must be a JavaScript identifier. It is followed by an equality sign (“=”) and a parsing expression. If the rule has a human-readable name, it is written as a JavaScript string between the name and separating equality sign. Rules need to be separated only by whitespace (their beginning is easily recognizable), but a semicolon (“;”) after the parsing expression is allowed.

The first rule can be preceded by an initializer — a piece of JavaScript code in curly braces (“{” and “}”). This code is executed before the generated parser starts parsing. All variables and functions defined in the initializer are accessible in rule actions and semantic predicates. The code inside the initializer can access options passed to the parser using the options variable. Curly braces in the initializer code must be balanced. Let's look at the example grammar from above using a simple initializer.

{
  function makeInteger(o) {
    return parseInt(o.join(""), 10);
  }
}

start
  = additive

additive
  = left:multiplicative "+" right:additive { return left + right; }
  / multiplicative

multiplicative
  = left:primary "*" right:multiplicative { return left * right; }
  / primary

primary
  = integer
  / "(" additive:additive ")" { return additive; }

integer "integer"
  = digits:[0-9]+ { return makeInteger(digits); }

The parsing expressions of the rules are used to match the input text to the grammar. There are various types of expressions — matching characters or character classes, indicating optional parts and repetition, etc. Expressions can also contain references to other rules. See detailed description below.

If an expression successfully matches a part of the text when running the generated parser, it produces a match result, which is a JavaScript value. For example:

  • An expression matching a literal string produces a JavaScript string containing matched text.
  • An expression matching repeated occurrence of some subexpression produces a JavaScript array with all the matches.

The match results propagate through the rules when the rule names are used in expressions, up to the start rule. The generated parser returns start rule's match result when parsing is successful.

One special case of parser expression is a parser action — a piece of JavaScript code inside curly braces (“{” and “}”) that takes match results of some of the the preceding expressions and returns a JavaScript value. This value is considered match result of the preceding expression (in other words, the parser action is a match result transformer).

In our arithmetics example, there are many parser actions. Consider the action in expression digits:[0-9]+ { return parseInt(digits.join(""), 10); }. It takes the match result of the expression [0-9]+, which is an array of strings containing digits, as its parameter. It joins the digits together to form a number and converts it to a JavaScript number object.

Parsing Expression Types

There are several types of parsing expressions, some of them containing subexpressions and thus forming a recursive structure:

"literal"
'literal'

Match exact literal string and return it. The string syntax is the same as in JavaScript. Appending i right after the literal makes the match case-insensitive.

.

Match exactly one character and return it as a string.

[characters]

Match one character from a set and return it as a string. The characters in the list can be escaped in exactly the same way as in JavaScript string. The list of characters can also contain ranges (e.g. [a-z] means “all lowercase letters”). Preceding the characters with ^ inverts the matched set (e.g. [^a-z] means “all character but lowercase letters”). Appending i right after the right bracket makes the match case-insensitive.

rule

Match a parsing expression of a rule recursively and return its match result.

( expression )

Match a subexpression and return its match result.

expression *

Match zero or more repetitions of the expression and return their match results in an array. The matching is greedy, i.e. the parser tries to match the expression as many times as possible. Unlike in regular expressions, there is no backtracking.

expression +

Match one or more repetitions of the expression and return their match results in an array. The matching is greedy, i.e. the parser tries to match the expression as many times as possible. Unlike in regular expressions, there is no backtracking.

expression ?

Try to match the expression. If the match succeeds, return its match result, otherwise return null. Unlike in regular expressions, there is no backtracking.

& expression

Try to match the expression. If the match succeeds, just return undefined and do not consume any input, otherwise consider the match failed.

! expression

Try to match the expression. If the match does not succeed, just return undefined and do not consume any input, otherwise consider the match failed.

& { predicate }

The predicate is a piece of JavaScript code that is executed as if it was inside a function. It gets the match results of labeled expressions in preceding expression as its arguments. It should return some JavaScript value using the return statement. If the returned value evaluates to true in boolean context, just return undefined and do not consume any input; otherwise consider the match failed.

The code inside the predicate can access all variables and functions defined in the initializer at the beginning of the grammar.

The code inside the predicate can also access location information using the location function. It returns an object like this:

{
  start: { offset: 23, line: 5, column: 6 },
  end:   { offset: 23, line: 5, column: 6 }
}

The start and end properties both refer to the current parse position. The offset property contains an offset as a zero-based index and line and column properties contain a line and a column as one-based indices.

The code inside the predicate can also access options passed to the parser using the options variable.

Note that curly braces in the predicate code must be balanced.

! { predicate }

The predicate is a piece of JavaScript code that is executed as if it was inside a function. It gets the match results of labeled expressions in preceding expression as its arguments. It should return some JavaScript value using the return statement. If the returned value evaluates to false in boolean context, just return undefined and do not consume any input; otherwise consider the match failed.

The code inside the predicate can access all variables and functions defined in the initializer at the beginning of the grammar.

The code inside the predicate can also access location information using the location function. It returns an object like this:

{
  start: { offset: 23, line: 5, column: 6 },
  end:   { offset: 23, line: 5, column: 6 }
}

The start and end properties both refer to the current parse position. The offset property contains an offset as a zero-based index and line and column properties contain a line and a column as one-based indices.

The code inside the predicate can also access options passed to the parser using the options variable.

Note that curly braces in the predicate code must be balanced.

$ expression

Try to match the expression. If the match succeeds, return the matched text instead of the match result.

label : expression

Match the expression and remember its match result under given label. The label must be a JavaScript identifier.

Labeled expressions are useful together with actions, where saved match results can be accessed by action's JavaScript code.

expression1 expression2 ... expressionn

Match a sequence of expressions and return their match results in an array.

expression { action }

Match the expression. If the match is successful, run the action, otherwise consider the match failed.

The action is a piece of JavaScript code that is executed as if it was inside a function. It gets the match results of labeled expressions in preceding expression as its arguments. The action should return some JavaScript value using the return statement. This value is considered match result of the preceding expression.

To indicate an error, the code inside the action can invoke the expected function, which makes the parser throw an exception. The function takes two parameters — a description of what was expected at the current position and optional location information (the default is what location would return — see below). The description will be used as part of a message of the thrown exception.

The code inside an action can also invoke the error function, which also makes the parser throw an exception. The function takes two parameters — an error message and optional location information (the default is what location would return — see below). The message will be used by the thrown exception.

The code inside the action can access all variables and functions defined in the initializer at the beginning of the grammar. Curly braces in the action code must be balanced.

The code inside the action can also access the text matched by the expression using the text function.

The code inside the action can also access location information using the location function. It returns an object like this:

{
  start: { offset: 23, line: 5, column: 6 },
  end:   { offset: 25, line: 5, column: 8 }
}

The start property refers to the position at the beginning of the expression, the end property refers to position after the end of the expression. The offset property contains an offset as a zero-based index and line and column properties contain a line and a column as one-based indices.

The code inside the action can also access options passed to the parser using the options variable.

Note that curly braces in the action code must be balanced.

expression1 / expression2 / ... / expressionn

Try to match the first expression, if it does not succeed, try the second one, etc. Return the match result of the first successfully matched expression. If no expression matches, consider the match failed.

Compatibility

Both the parser generator and generated parsers should run well in the following environments:

  • Node.js 0.10.0+
  • Internet Explorer 8+
  • Edge
  • Firefox
  • Chrome
  • Safari
  • Opera

Development

PEG.js is developed by David Majda (@dmajda). The Bower package is maintained by Michel Krämer (@michelkraemer).

You are welcome to contribute code. Unless your contribution is really trivial you should get in touch with me first — this can prevent wasted effort on both sides. You can send code both as a patch or a GitHub pull request.

Note that PEG.js is still very much work in progress. There are no compatibility guarantees until version 1.0.

changelog

Change Log

This file documents all notable changes to PEG.js. The releases follow semantic versioning.

0.10.0

Released: August 19, 2016

Major Changes

  • Parsers can be generated in multiple module formats. The available formats are: CommonJS (the default), AMD, UMD, globals, and bare (not available from the command-line).

    The format can be specified using the format option of the peg.generate function or the --format option on the command-line.

    It is also possible to specify parser dependencies using the dependencies option of the peg.generate function or the --dependency/-d option on the command-line. This is mainly useful for the UMD format, where the dependencies are translated into both AMD dependencies and CommonJS require calls.

  • Browser version of PEG.js is now in the UMD format. This means it will try to detect AMD or Node.js/CommonJS module loader and define itself as a module. If no loader is found, it will export itself using a global variable.

  • API polishing. The peg.buildParser function was renamed to peg.generate. The global variable the browser version of PEG.js is available in when no loader is detected was renamed from PEG to peg.

  • CLI improvements. There is new --output/-o command-line option which allows to specify the output file. The old way of specifying the output file using a second argument was removed. To make room for the new -o option the old one (a shortcut for --optimize) was renamed to -O. All these changes make PEG.js conform to traditional compiler command-line interface.

    It is now also possible to use - as a file name on the command-line (with the usual meaning of standard input/output).

  • Improved error messages. Both messages produced by PEG.js and generated parsers were improved.

  • Duplicate rule definitions are reported as errors.

  • Duplicate labels are reported as errors.

Minor Changes

  • Exposed the AST node visitor builder as peg.compiler.visitor. This is useful mainly for plugins which manipulate the AST.

  • Exposed the function which builds messages of exceptions produced by generated parsers as SyntaxError.buildMessage. This is useful mainly for customizing these error messages.

  • The error and expected functions now accept an optional location parameter. This allows to customize the location in which the resulting syntax error is reported.

  • Refactored expectations reported in the expected property of exceptions produced by generated parsers. They are no longer de-duplicated and sorted, their format changed to be more machine-readable, and they no longer contain human-readable descriptions.

  • The found property of exceptions produced by the error function is now set to null.

  • Removed access to the parser object in parser code via the parser variable.

  • Made handling of optional parameters consistent with ES 2015. Specifically, passing undefined as a parameter value is now equivalent to not passing the parameter at all.

  • Renamed several compiler passes.

  • Generated parsers no longer consider \r, \u2028, and \u2029 as newlines (only \n and \r\n).

  • Simplified the arithmetics example grammar.

  • Switched from first/rest to head/tail in PEG.js grammar and example grammars.

  • Started using ESLint instead of JSHint and fixed various problems it found.

  • Added contribution guidelines.

  • Removed support for io.js.

Bug Fixes

  • Fixed bin/pegjs so that invoking it with one non-option argument which is an extension-less file doesn’t cause that file to be overwritten.

  • Fixed label scoping so that labels in expressions like (a:"a") or (a:"a" b:"b" c:"c") aren’t visible from the outside.

  • Fixed escaping of generated JavaScript strings & regexps to also escape DEL (U+007F).

  • Fixed the JSON example grammar to correctly handle characters with code points above U+10FF in strings.

  • Fixed multiple compatibility issues of tools/impact on OS X.

  • Fixed slow deduplication of expectation descriptions.

Complete set of changes

0.9.0

Released: August 30, 2015

Major Changes

  • Tracing support. Parsers can be compiled with support for tracing their progress, which can help debugging complex grammars. This feature is experimental and is expected to evolve over time as experience is gained. More details

  • Infinite loop detection. Grammar constructs that could cause infinite loops in generated parsers are detected during compilation and cause errors.

  • Improved location information API. The line, column, and offset functions available in parser code were replaced by a single location function which returns an object describing the current location. Similarly, the line, column, and offset properties of exceptions were replaced by a single location property. The location is no longer a single point but a character range, which is meaningful mainly in actions where the range covers action’s expression. More details

  • Improved error reporting. All exceptions thrown when generating a parser have associated location information. And all exceptions thrown by generated parser and PEG.js itself have a stack trace (the stack property) in environments that support Error.captureStackTrace.

  • Strict mode code. All PEG.js and generated parser code is written using JavaScript strict mode.

Minor Changes

  • Labels behave like block-scoped variables. This means parser code can see labels defined outside expressions containing code.

  • Empty sequences are no longer allowed.

  • Label names can’t be JavaScript reserved words.

  • Rule and label names can contain Unicode characters like in JavaScript.

  • Rules have to be separated either by ; or a newline (until now, any whitespace was enough).

  • The PEG.js grammar and all the example grammars were completely rewritten. This rewrite included a number of cleanups, formatting changes, naming changes, and bug fixes.

  • The parser object can now be accessed as parser in parser code.

  • Location information computation is faster.

  • Added support for Node.js >= 0.10.x, io.js, and Edge. Removed support for Node.js < 0.10.x.

Bug Fixes

  • Fixed left recursion detector which missed many cases.

  • Fixed escaping of U+0100—U+107F and U+1000—U+107F in generated code and error messages.

  • Renamed parse and SyntaxError to peg$parse and peg$SyntaxError to mark them as internal identifiers.

Complete set of changes

0.8.0

Released: December 24, 2013

Big Changes

  • Completely rewrote the code generator. Among other things, it allows optimizing generated parsers for parsing speed or code size using the optimize option of the PEG.buildParser method or the --optimize/-o option on the command-line. All internal identifiers in generated code now also have a peg$ prefix to discourage their use and avoid conflicts. [#35, #92]

  • Completely redesigned error handling. Instead of returning null inside actions to indicate match failure, new expected and error functions can be called to trigger an error. Also, expectation inside the SyntaxError exceptions are now structured to allow easier machine processing. [#198]

  • Implemented a plugin API. The list of plugins to use can be specified using the plugins option of the PEG.buildParser method or the --plugin option on the command-line. Also implemented the --extra-options and --extra-options-file command-line options, which are mainly useful to pass additional options to plugins. [#106]

  • Made offset, line and column functions, not variables. They are now available in all parsers and return lazily-computed position data. Removed now useless trackLineAndColumn option of the PEG.buildParser method and the --track-line-and-column option on the command-line.

  • Added a new text function. When called inside an action, it returns the text matched by action's expression. [#131]

  • Added a new $ operator. It extracts matched strings from expressions.

  • The ? operator now returns null on unsuccessful match.

  • Predicates now always return undefined.

  • Replaced the startRule parameter of the parse method in generated parsers with more generic options parameter. The start rule can now be specified as the startRule option. The options parameter can be also used to pass custom options to the parser because it is visible as the options variable inside parser code. [#37]

  • The list of allowed start rules of a generated parser now has to be specified explicitly using the allowedStartRules option of the PEG.buildParser method or the --allowed-start-rule option on the command-line. This will make certain optimizations like rule inlining easier in the future.

  • Removed the toSource method of generated parsers and introduced a new output option of the PEG.buildParser method. It allows callers to specify whether they want to get back the parser object or its source code.

  • The source code is now a valid npm package. This makes using development versions easier. [#32]

  • Generated parsers are now ~25% faster and ~62%/~3% smaller (when optimized for size/speed) than those generated by 0.7.0.

  • Requires Node.js 0.8.0+.

Small Changes

  • bin/pegjs now outputs just the parser source if the value of the --export-var option is empty. This makes embedding generated parsers into other files easier. [#143]

  • Changed the value of the name property of PEG.GrammarError instances from “PEG.GrammarError” to just “GrammarError”. This better reflects the fact that PEG.js can get required with different variable name than PEG.

  • Setup prototype chain for PEG.GrammarError correctly.

  • Setup prototype chain for SyntaxError in generated parsers correctly.

  • Fixed error messages in certain cases with trailing input [#119]

  • Fixed code generated for classes starting with \^. [#125]

  • Fixed too eager proxy rules removal. [#137]

  • Added a license to all vendored libraries. [#207]

  • Converted the test suite from QUnit to Jasmine, cleaning it up on the way.

  • Travis CI integration.

  • Various internal code improvements and fixes.

  • Various generated code improvements and fixes.

  • Various example grammar improvements and fixes.

  • Improved README.md.

  • Converted CHANGELOG to Markdown.

0.7.0

Released: April 18, 2012

Big Changes

  • Added ability to pass options to PEG.buildParser.

  • Implemented the trackLineAndColumn option for PEG.buildParser (together with the --track-line-and-column command-line option). It makes the generated parser track line and column during parsing. These are made available inside actions and predicates as line and column variables.

  • Implemented the cache option for PEG.buildParser (together with the --cache command-line option). This option enables/disables the results cache in generated parsers, resulting in dramatic speedup when the cache is disabled (the default now). The cost is breaking the linear parsing time guarantee.

  • The current parse position is visible inside actions and predicates as the offset variable.

  • Exceptions thrown by the parser have offset, expected and found properties containing machine-readable information about the parse failure (based on a patch by Marcin Stefaniuk).

  • Semantic predicates have access to preceding labels. [GH-69]

  • Implemented case-insensitive literal and class matching. [GH-34]

  • Rewrote the code generator — split some computations into separate passes and based it on a proper templating system (Codie).

  • Rewrote variable handling in generated parsers in a stack-like fashion, simplifying the code and making the parsers smaller and faster.

  • Adapted to Node.js 0.6.6+ (no longer supported in older versions).

  • Dropped support for IE < 8.

  • As a result of several optimizations, parsers generated by 0.7.0 are ~6.4 times faster and ~19% smaller than those generated by 0.6.2 (as reported by /tools/impact).

Small Changes

  • Fixed reported error position when part of the input is not consumed. [GH-48]

  • Fixed incorrect disjunction operator in computeErrorPosition (original patch by Wolfgang Kluge).

  • Fixed regexp for detecting command-line options in /bin/pegjs. [GH-51]

  • Generate more efficient code for empty literals (original patch by Wolfgang Kluge).

  • Fixed comment typos (patches by Wolfgang Kluge and Jason Davies). [GH-59]

  • Fixed a typo in JavaScript example grammar. [GH-62]

  • Made copy & paste inclusion of the PEG.js library into another code easier by changing how the library is exported.

  • Improved the copyright comment and the “Generated by...” header.

  • Replaced Jakefile with Makefile.

  • Added make hint task that checks all JavaScript files using JSHint and resolved all issues it reported. All JavaScript files and also generated parsers are JSHint-clean now.

  • Fixed output printed during test failures (expected value was being printed instead of the actual one). Original patch by Wolfgang Kluge.

  • Added a /tools/impact script to measure speed and size impact of commits.

  • Various generated code improvements and fixes.

  • Various internal code improvements and fixes.

  • Improved README.md.

0.6.2

Released: August 20, 2011

Small Changes

  • Reset parser position when action returns null.

  • Fixed typo in JavaScript example grammar.

0.6.1

Released: April 14, 2011

Small Changes

  • Use --ascii option when generating a minified version.

0.6.0

Released: April 14, 2011

Big Changes

  • Rewrote the command-line mode to be based on Node.js instead of Rhino — no more Java dependency. This also means that PEG.js is available as a Node.js package and can be required as a module.

  • Version for the browser is built separately from the command-line one in two flavors (normal and minified).

  • Parser variable name is no longer required argument of bin/pegjs — it is module.exports by default and can be set using the -e/--export-var option. This makes parsers generated by /bin/pegjs Node.js modules by default.

  • Added ability to start parsing from any grammar rule.

  • Added several compiler optimizations — 0.6 is ~12% faster than 0.5.1 in the benchmark on V8.

Small Changes

  • Split the source code into multiple files combined together using a build system.

  • Jake is now used instead of Rake for build scripts — no more Ruby dependency.

  • Test suite can be run from the command-line.

  • Benchmark suite can be run from the command-line.

  • Benchmark browser runner improvements (users can specify number of runs, benchmarks are run using setTimeout, table is centered and fixed-width).

  • Added PEG.js version to “Generated by...” line in generated parsers.

  • Added PEG.js version information and homepage header to peg.js.

  • Generated code improvements and fixes.

  • Internal code improvements and fixes.

  • Rewrote README.md.

0.5.1

Released: November 28, 2010

Small Changes

  • Fixed a problem where “SyntaxError: Invalid range in character class.” error appeared when using command-line version on Widnows (GH-13).

  • Fixed wrong version reported by bin/pegjs --version.

  • Removed two unused variables in the code.

  • Fixed incorrect variable name on two places.

0.5

Released: June 10, 2010

Big Changes

  • Syntax change: Use labeled expressions and variables instead of $1, $2, etc.

  • Syntax change: Replaced : after a rule name with =.

  • Syntax change: Allow trailing semicolon (;) for rules

  • Semantic change: Start rule of the grammar is now implicitly its first rule.

  • Implemented semantic predicates.

  • Implemented initializers.

  • Removed ability to change the start rule when generating the parser.

  • Added several compiler optimizations — 0.5 is ~11% faster than 0.4 in the benchmark on V8.

Small Changes

  • PEG.buildParser now accepts grammars only in string format.

  • Added “Generated by ...” message to the generated parsers.

  • Formatted all grammars more consistently and transparently.

  • Added notes about ECMA-262, 5th ed. compatibility to the JSON example grammar.

  • Guarded against redefinition of undefined.

  • Made bin/pegjs work when called via a symlink (issue #1).

  • Fixed bug causing incorrect error messages (issue #2).

  • Fixed error message for invalid character range.

  • Fixed string literal parsing in the JavaScript grammar.

  • Generated code improvements and fixes.

  • Internal code improvements and fixes.

  • Improved README.md.

0.4

Released: April 17, 2010

Big Changes

  • Improved IE compatibility — IE6+ is now fully supported.

  • Generated parsers are now standalone (no runtime is required).

  • Added example grammars for JavaScript, CSS and JSON.

  • Added a benchmark suite.

  • Implemented negative character classes (e.g. [^a-z]).

  • Project moved from BitBucket to GitHub.

Small Changes

  • Code generated for the character classes is now regexp-based (= simpler and more scalable).

  • Added \uFEFF (BOM) to the definition of whitespace in the metagrammar.

  • When building a parser, left-recursive rules (both direct and indirect) are reported as errors.

  • When building a parser, missing rules are reported as errors.

  • Expected items in the error messages do not contain duplicates and they are sorted.

  • Fixed several bugs in the example arithmetics grammar.

  • Converted README to GitHub Flavored Markdown and improved it.

  • Added CHANGELOG.

  • Internal code improvements.

0.3

Released: March 14, 2010

  • Wrote README.

  • Bootstrapped the grammar parser.

  • Metagrammar recognizes JavaScript-like comments.

  • Changed standard grammar extension from .peg to .pegjs (it is more specific).

  • Simplified the example arithmetics grammar + added comment.

  • Fixed a bug with reporting of invalid ranges such as [b-a] in the metagrammar.

  • Fixed --start vs. --start-rule inconsistency between help and actual option processing code.

  • Avoided ugliness in QUnit output.

  • Fixed typo in help: parserVarparser_var.

  • Internal code improvements.

0.2.1

Released: March 8, 2010

  • Added pegjs- prefix to the name of the minified runtime file.

0.2

Released: March 8, 2010

  • Added Rakefile that builds minified runtime using Google Closure Compiler API.

  • Removed trailing commas in object initializers (Google Closure does not like them).

0.1

Released: March 8, 2010

  • Initial release.