Note: based upon #321 and should be rebased once that's merged
This gives further uniformity in their interfaces and allows more common
handling.
The next step will be for all the `Expr.make_*` functions to work on
expressions
annotated with the `'a mark` type, correctly propagating type
information when
it is present. Then we could even imagine early propagation of type
information (without complete inference), which could for example be
used for
overloaded operator disambiguation.
This gives further uniformity in their interfaces and allows more common
handling.
The next step will be for all the `Expr.make_*` functions to work on expressions
annotated with the `'a mark` type, correctly propagating type information when
it is present. Then we could even imagine early propagation of type
information (without complete inference), which could for example be used for
overloaded operator disambiguation.
Ok this one seems big but it's mostly just `sed` calls. It's very
optional. It's based on #321 so that should definitely be merged first.
For handling marks we usually have two mutually recursive types `foo`
and `marked_foo`. Types, expressions, etc.
Now, throughout, I found that we use `marked_foo` much more often than
`foo` when using the type. Which is good.
But I feel the naming pushes in favor of using the base `foo` type. So
this proposal does a little inversion:
- `marked_foo` → is renamed to → `foo` for use throughout
- `foo` → is renamed to → `naked_foo` for clarity
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
