Using them will lead to "not supported yet" errors soon after, but it's a start
to get to handling separate modules.
The idea is that `foo` can now also be `Bar.foo`, `Bar.Baz.foo`, `foo.Struc.fld`
can be `foo.Bar.Baz.Struc.fld`, etc.
The next steps are to enable the lookups to handle this paths, and to provide
ways to load the external modules to feed these lookups.
Closes#373
This forbids expressions such as `a and b or c`, avoiding the need to set an
implicit priority between `and`, `or` and `xor`, which I find error-prone.
Instead, when that appears, a message asking for explicit parentheses will be
shown to the user.
Implementation note: since that would be extremely tedious to do in the parser
directly, the parser is set to allow right-associativity without discrimination
for the logical operators, and the check is done during desugaring. This
required to explicit parentheses in the surface AST to discriminate the case
where the priority was explicit.
In particular `CONSTRUCTOR` is no longer valid for paths & modules, so let's
switch to the more usual LIDENT / UIDENT for lower- or upper- case idents.
cd compiler/surface
sed -i 's/VERTICAL/BAR/g' *
sed -i 's/BRACKET/BRACE/g' *
sed -i 's/SQUARE/BRACKET/g' *
sed -i 's/IDENT/LIDENT/g' *
sed -i 's/CONSTRUCTOR/UIDENT/g' *
Define a single expression rule with disambiguation using token priorities
instead of the many layers of intermediate rules with explicit sub-terms.
Also replaces `in` for collection operations (`x+1 for foo in [1;2]`) with
`among` which helps a lot.
Overloads are powerful, but let's clearly draw the line right now between
convenience and type safety, for when someone else will want to add new
operators.
