As discussed in #549
NOTE: This implements only the direct tuple member access (syntax `foo.N` with N a
number)
- It seems more efficient to wait for the general pattern-matching rewrite to
handle pattern-matching on tuples
- Until then we keep the (now obsolete) `let (x, y) = pair in x` syntax, to
leave time for updates, but we won't be documenting it
Closes#592
A new node is added in `desugared`, and translated into an exploded structure
literal during translation to `scopelang`. The main reason to put it there is
that it needs to be after disambiguation, since that is used to discover the
type of the structure that is being updated.
Through the syntax `var_name state state_name`.
Addresses #567, but
- requires documentation
- explicitely accessing states of the variable being defined is not allowed at
the moment (warning proposed in #567 requires a whole-expression check, which
is better done some place else entirely)
The primary use-case for this was to be able to run computations on a list of
structures, then return an updated list with some fields in the structures
modified : that is what we need for distribution of tax amounts among household
members, for example.
This patch has a few components:
- Addition of a test as an example for tax distributions
- Added a transformation, performed during desugaring, that -- where lists are
syntactically expected, i.e. after the `among` keyword -- turns a (syntactic)
tuple of lists into a list of tuples ("zipping" the lists)
- Arg-extremum transformation was also fixed to use an intermediate list instead
of computing the predicate twice
- For convenience, allow to bind multiple variables in most* list
operations (previously only `let in` and functions allowed it)
- Fixed the printer for tuples to differentiate them from lists
*Note: tuples are not yet allowed on the left-hand side of filters and
arg-extremums for annoying syntax conflict reasons.
The module is renamed to `Mark`, and functions renamed to avoid redundancy:
`Marked.mark` is now `Mark.add`
`Marked.unmark` is now `Mark.remove`
`Marked.map_under_mark` is now simply `Mark.map`
etc.
`Marked.same_mark_as` is replaced by `Mark.copy`, but with the arguments
swapped (which seemed more convenient throughout)
Since a type `Mark.t` would indicate a mark, and to avoid confusion, the type
`Marked.t` is renamed to `Mark.ed` as a shorthand for `Mark.marked` ; this part
can easily be removed if that's too much quirkiness.
Previously the `state` marker for rules was in a weird position:
```catala
rule foo under condition bar
consequence state st fulfilled
```
This patch unifies the syntax with definitions, now using instead:
```catala
rule foo state st
under condition bar
consequence fulfilled.
```
This adds a few positions to the parser, and tweaks some others, vastly
improving the reporting of some errors (inconsistent functions definitions, but
also exceptions cycles, etc.)
* temporary and undocumented while waiting for discussion an approval
* previous patches already allowed definition (at toplevel) but there was no
syntax for calls
* no syntax for multi-args _local_ functions yet
... that's one less thing to do
Two notes:
- Updated the syntax errors in
examples/NSW_community_gaming/tests/test_nsw_social_housie.catala_en ; those
probably aren't expected though, but fixing them is outside my purpose here
- There is consensus on keeping the error messages in English; however, here,
the error messages include hints on the syntax to use, which are only valid
for users of the English syntax.
* A possible solution would be to apply cppo on parser.messages, using the
macros already defined in lexer_LANG.cppo.ml. However, we would then need to
tweak (or duplicate!) the parser to use the messages for the correct language.
Furthermore, updating and merging the file on parser updates would need
special care.
* Another, maybe easier solution would be manual processing, using a custom
escape in the parser messages and rewriting that at runtime when printing
the message. We would need to extract a runtime version of the macro
definitions though.
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.
This uses the same disambiguation mechanism put in place for
structures, calling the typer on individual rules on the desugared AST
to propagate types, in order to resolve ambiguous operators like `+`
to their strongly typed counterparts (`+!`, `+.`, `+$`, `+@`, `+$`) in
the translation to scopelang.
The patch includes some normalisation of the definition of all the
operators, and classifies them based on their typing policy instead of
their arity. It also adds a little more flexibility:
- a couple new operators, like `-` on date and duration
- optional type annotation on some aggregation constructions
The `Shared_ast` lib is also lightly restructured, with the `Expr`
module split into `Type`, `Operator` and `Expr`.
Quite a few changes are included here, some of which have some extra
implications visible in the language:
- adds the `Scope of { -- input_v: value; ... }` construct in the language
- handle it down the pipeline:
* `ScopeCall` in the surface AST
* `EScopeCall` in desugared and scopelang
* expressions are now traversed to detect dependencies between scopes
* transformed into a normal function call in dcalc
- defining a scope now implicitely defines a structure with the same name, with
the output variables of the scope defined as fields. This allows us to type
the return value from a scope call and access its fields easily.
* the implications are mostly in surface/name_resolution.ml code-wise
* the `Scope_out` struct that was defined in scope_to_dcalc is no longer
needed/used and the fields are no longer renamed (changes some outputs; the
explicit suffix for variables with multiple states is ignored as well)
* one benefit is that disambiguation works just like for structures when there
are conflicts on field names
* however, it's now a conflict if a scope and a structure have the same
name (side-note: issues with conflicting enum / struct names or scope
variables / subscope names were silent and are now properly reported)
- you can consequently use scope names as types for variables as well. Writing
literals is not allowed though, they can only be obtained by calling the
scope.
Remaining TODOs:
- context variables are not handled properly at the moment
- error handling on invalid calls
- tests show a small error message regression; lots of examples will need
tweaking to avoid scope/struct name or struct fields / output variable
conflicts
- add a `->` syntax to make struct field access distinct from scope output var
access, enforced with typing. This is expected to reduce confusion of users
and add a little typing precision.
- document the new syntax & implications (tutorial, cheat-sheet)
- a consequence of the changes is that subscope variables also can now be typed.
A possible future evolution / simplification would be to rewrite subscopes as
explicit scope calls early in the pipeline. That could also allow to manipulate
them as expressions (bind them in let-ins, return them...)
