(first working dynload test with compilation done by manual calls to ocaml)
A few pieces of the puzzle:
* Loading of interfaces only from Catala files
* Registration of toplevel values in modules compiled to OCaml, to allow access
using dynlink
* Shady conversion from OCaml runtime values to/from Catala expressions, to
allow interop (ffi) of compiled modules and the interpreter
Interstingly enough, it was already implemented in the Python backend.
Required to implement *pro rata temporis*, which the US tax section 121 does
make use of.
Only allowed for durations expressed in days (as returned by `<date> - <date>`),
of course.
it's unlikely to be used in any law, and likely to be cause for confusion.
best of all, the new operator has a different return type, which
ensures no inconsistency with the change can get overlooked.
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`.
This is a WIP. Current version 0.0.2 of `dates_calc` is in the process of being published, so I guess the CI should fail currently.
- [x] Test current implementation
- [x] I commented out the `duration / duration` operator, can we remove it?
- [x] Need to add support for first and last day of month
- [x] Finish porting the Z3 backend to dates_calc
