Little change in the source grammar now does not change variables in all
the generated code. This is helpful especially when one has the
generated grammar stored in a VCS (this is true e.g. for our
metagrammar).
Labeled expressions lead to more maintainable code and also will allow
certain optimizations (we can ignore results of expressions not passed
to the actions).
This does not speed up the benchmark suite execution statistically
significantly on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.43 kB/s 28.46 kB/s
2 28.38 kB/s 28.56 kB/s
3 28.22 kB/s 28.58 kB/s
4 28.76 kB/s 28.55 kB/s
5 28.57 kB/s 28.48 kB/s
---------------------------------
Average 28.47 kB/s 28.53 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4
I'll introduce labelled expressions shortly and I want to use ":" as a
label-expression separator. This change avoids conflict between the two
meanings of ":". (What would e.g. "foo: 'bar'" mean? Rule "foo"
matching string "bar", or string "bar" labelled "foo"?)
The mistakes weren't caught because the first one introduces a syntax
error, causing the whole test suite not to load. Unfortunately, QUnit
didn't complain so I missed this.
The real commit these changes belong to is
33a1a7c1e9.
The action now computes the number of passed parameters during the code
generation and the parameters are declared directly as $1, $2, etc. in the
generated function.
This does not speed up the benchmark suite execution statistically significantly
on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.68 kB/s 29.08 kB/s
2 28.77 kB/s 28.72 kB/s
3 28.89 kB/s 28.78 kB/s
4 28.84 kB/s 28.57 kB/s
5 28.86 kB/s 28.84 kB/s
---------------------------------
Average 28.81 kB/s 28.80 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2
This does not speed up the benchmark suite execution statistically significantly
on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.84 kB/s 28.75 kB/s
2 28.76 kB/s 28.69 kB/s
3 28.72 kB/s 28.69 kB/s
4 28.84 kB/s 28.93 kB/s
5 28.82 kB/s 28.70 kB/s
---------------------------------
Average 28.80 kB/s 28.75 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko)
Chrome/5.0.342.9 Safari/533.2
This does not speed up the benchmark suite execution statistically significantly
on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 28.72 kB/s 28.84 kB/s
2 28.84 kB/s 28.76 kB/s
3 28.83 kB/s 28.72 kB/s
4 28.81 kB/s 28.84 kB/s
5 28.76 kB/s 28.82 kB/s
---------------------------------
Average 28.79 kB/s 28.80 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2
This and also speeds up the benchmark suite execution by 7.83 % on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 26.17 kB/s 28.16 kB/s
2 26.05 kB/s 28.16 kB/s
3 25.99 kB/s 28.10 kB/s
4 26.13 kB/s 28.11 kB/s
5 26.14 kB/s 28.07 kB/s
---------------------------------
Average 26.10 kB/s 28.14 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.7 Safari/533.2
The Rhino bug that prevented inclusion of \uFEFF among the whitespace characters
is no longer relevant here because we compile character classes into regexps
now, which avoids the infinite recursion.
David Majda