The module is a simple wrapper around the lex/yacc generated parser, exporting a function to parse a file. It’s not intended for usage, it’s more for testing or as a template to use a parser, as the errors are swallowed.
[Parse error] How can one react upon a general parse error? Is the parse-module a serious module at all or rather a test for the parser? To make it usable, mustn’t we let through the exceptions?
[Parse error] Why is My_Parse_error part of the abstract syntax?
[Operator precedence] It seems that the yacc of Ocaml is more powerful than the one of Java. It can resolve the operator precedeces, even if the operators are combined in separate rules and not “inlined” in the rules for expression.
[Nil and skip] The expression () is not the nil-value, it’s not a value at all. It’s an expression “without” a value (cf. page 516), i.e., of type Unit. We represent it in the abstract syntax as empty sequence.
[S/R] There is a shift/reduce conflict for type declarations and the same one for function declarations.
The reason is that one connected list of type declarations is not separated by anything and since the list of type declarations is itself part of a list of declarations, the parser does not know whether the next phrase starting with the TYPE-keyword belongs to the inner list of type declarations or is the first element of the next list of type declarations. According to the specification, the type declarations belong together until there’s an intervening other declation, i.e., a variable or a function declaration.
A shift-reduce conflict is resolved by shifting. In our case this means that the list of type declarations is extended, as we intend, so the shift-reduce conflict is harmless.
One could make those conflicts go away to introduce some separating tokens between single type declarations but not between general declarations. Likewise one could do it the other way around or to introduce two different kind of separating tokens.
[Parsing l-values] Writing the grammar for l-values straightforwardly, gives a shift-reduce conflict.
expr: | lvalue | vl_expr | id LBRACKET expr RBRACKET OF expr FO // array creation ... vl_expr: .. | lvalue ASSGN expr lvalue: id | lvalue DOT id | lvalue LBRACKET expr RBRACKET ;
Probably this is also the error mentioned at page 82 of [App98b]. The solution is to splice out the clause id LBRACKET expr RBRACKET.
I can parse the following: