There was an error in the syntax of tuple projection (no parentheses
are needed, in fact).
Another issue was a wrong Markdown layout for lists (my fault).
I added a type annotation for the variable iterating a
collection, which is also now marked as "map", "set" or "list".
I fixed and refactored the pretty-printer for the AST.
ParserLog: Finished the AST pretty-printer.
ParserMain: The CLI "ast" is now "ast-tokens" and the new "ast"
calls the AST pretty-printer.
Bug: Added nat literals as patterns.
AST: Removed unary constructor TupleInj.
Parser and simplifier:
- The rule "cartesian" is now properly stratified.
- Parenthesised expressions now correctly create EPar nodes.
- I aligned the names of the tokens in common with Ligodity.
- I removed the "down" and "step" clauses in loops.
- Note: the stratification of the rule "pattern" in the
previous commit has the pleasant effect to remove a call
to "corner_case" in function "simpl_case" of the
file "2-simplify/pascaligo.ml".
- Added more cases to the pretty-printer of the AST.
LexToken, AST: Tiny refactoring.
Bug: Added the making of the AST node PBytes.
Parser: The rule "pattern" was not properly stratified (the
constructor "PCons" was always produced, even when no consing was
done (now a fall-through to "core_pattern").
Bug: When sharing the lexers between Ligodity and Pascaligo, a
regression was introduced with the lexing of symbols. Indeed,
symbols specific to Ligodity (like "<>") and
Pascaligo (like "=/=") were scanned, but the
function "LexToken.mk_sym" for each only accepted their own,
yielding to an assertion to be invalidated. Fix: I created an
error "sym_err" now to gracefully handle that situation and
provide a hint to the programmer (to wit, to check the LIGO
syntax in use).
WIP: Started to write pretty-printing functions for the nodes of
the AST.
CLI: The option "--verbose=ast" now calls that function instead
of printing the tokens from the AST. When the pretty-printer is
finished, the option for printing the tokens will likely
be "--verbose=ast-tokens".
Right now I'm concerned that the way this generates the code is inefficient, in particular this line:
`in ok @@ (access_path, key', value', loc)`
Since the comments [on my code for the set patch](https://gitlab.com/ligolang/ligo/merge_requests/127)
warned that repeated generation of the access path is a bad idea(?). In any case this does work, so
it's something I can improve on.
