Adela Vais - SAOC Milestone 4 Update 3 - Dlang GLR Parser for GNU Bison
Adela Vais
adela.vais99 at gmail.com
Sat Jan 16 22:09:04 UTC 2021
On Thursday, 7 January 2021 at 23:30:29 UTC, Adela Vais wrote:
>>>>>>>[...]
Hello!
As of the last update:
- I modified the calc example to use lookahead correction. Using
my last week's work on an unmodified calc example, I modified
this program to use a push-parser.
- I made some small style fixes in the examples and submitted
them for review along with the std.conv.parse modification
started last week. The enhancement to parse was introduced in
Dlang v2.095.0, so we will support both versions for the calc
example: the one demonstrating the new parse feature, and the one
using the old code. [1]
- I started working on token constructors. [2] This feature works
in the C++ parser only using the '%define api.value.type variant'
option.
By default, the user must write a union containing all the
different types of values needed for yylex(), and then use them
when declaring the tokens:
%union {
int ival;
}
[...]
%token <ival> NUM "number"
Variant allows the user to simply write:
%token <int> NUM "number"
D does not support this feature, but I plan to introduce it in
the near future (not necessarily during SAOC).
From yylex(), the user must return a Symbol by calling its
constructor. This constructor does not check if the TokenKind and
the value correspond in any way, so the user can return
Symbol(TokenKind.NUMBER, "I am a string") and the error will be
caught much later in the program, and, of course, at runtime.
As a solution to this, the C++ parser provides the option of
calling the make_<token_name> function (example: make_NUMBER),
which calls the Symbol constructor with the correct arguments,
and generates compile-time errors. I want to provide this feature
for D (modified to be called as Symbol.NUMBER(someNumber)).
The C++ parser generates the make_ functions with M4, so all the
functions are put in a header file for the user. I want to limit
the space occupied by these methods by generating them using D.
[3] I created a version that does not use variant, as a proof of
concept that this task can be done from D. But once I add support
for variant, the token constructors should work without
modifications.
The plan for the next week of #SAOC2020:
- Continue working on the above. Push-parser next steps:
* I have to do more correctness and speed tests for both
versions (with and without lookahead correction).
* Start integrating it in the D backend.
[1]: https://github.com/adelavais/bison/tree/calc-example-fix
[2]: https://github.com/adelavais/bison/tree/token-constructors
[3]:
https://github.com/adelavais/bison/blob/token-constructors/tests/testsuite.dir/582/calc.d#L544
More information about the Digitalmars-d
mailing list