This will allow to unify with types used earlier in the
pipeline (`Scopelang.Ast.typ`).
It seems cleaner! But some areas may warrant a later clean-up, in particular
handling of options and their types in the backends, or possible name conflicts
of structs/enums with built-in types when printing.
This will allow to unify with types used earlier in the
pipeline (`Scopelang.Ast.typ`).
It seems cleaner! But some areas may warrant a later clean-up, in particular
handling of options and their types in the backends, or possible name conflicts
of structs/enums with built-in types when printing.
Note that there were significant differences between the two printers (see the test diff!). Overall the `dcalc` one seemed newer so that's what I took, with only the required additions from `lcalc` (exceptions, raise and catch)
Handling code should now be reasonably well sorted between `Shared_ast.{Var,Expr,Scope,Program}`
The function parameters (e.g. `make_let_in`) could be removed from the
scope handling functions since now the types are compatible, which
makes them much easier to read.
Follow-up of #287, #266 and #165.
Time spent
Pair programming sessions
Before 2022-07-11: 50h (50 h for each person of the pair programming duo)
Refactoring sessions
Before 2022-07-11: 24 h
2022-07-14: 3 h
Legal research sessions
Before 2022-07-11: 21,5 h
Testing and debugging
Before 2022-07-11: 13,5 h
2022-07-11: 3 h with Denis
2022-07-13: 2 h with Denis
2022-07-14: 1 h with Denis
2022-07-16: 2 h with Denis
2022-07-19: 2 h with Denis
2022-07-21: 2 h with Denis
2022-08-11: 6 h with Denis
2022-08-15: 4 h with Denis
2022-08-16: 2 h with Denis
UI and form
2022-08-09: 8 h with Denis
2022-08-10: 8 h with Denis
2022-08-15: 2 h with Denis
2022-08-16: 2 h with Denis
2022-08-17: 6 h with Denis
2022-08-18: 4 h with Denis
The huge benefit of this approach is that almost no changes are needed and we get compatible types between dcalc and lcalc, allowing to deduplicate a few functions.
It might not be the best in the long run: there are still benefits in factorising small parts of the AST as suggested in #157, and this forces a central AST definition that makes the nanopass-like approach a bit less legible.
Still, I think it's a step in the right direction and it doesn't really lock us in keeping to use the big GADT (as the minimal cascade of changes show).
