*Disclaimer*: This is intended for discussion
My impression is that the with-exceptions backend is to be superseded by the
without-exception backend, which is more general and more efficient. Therefore,
seeing the added complexity of maintaining the two in parallel, I see no good
reason to keep the with-exceptions version now that the equivalence of their
semantics have been proved.
It will also be nice to reduce divergences between the different backends ; and
this should make further simplifications possible (e.g. some thunkings may no
longer be needed)
Of course I am ready to hear arguments in favor of keeping it, be it in the mid-
or long-term.
This patch removes the `--avoid-exceptions` flag, making it the only option, and
the corresponding `with_exceptions` variant of the dcalc->lcalc translation. It
doesn't do further simplifications.
We need the new dates_calc and sedlex
Debug notes:
We need the latest ocamlpro/ocaml image (2024-05-26) to get the release of
dates_calc. Unfortunately, it breaks: `pip install gmpy2` could not find
pre-built binaries, so it would "transparently" try to recompile and then
complain about obscure system packages missing (mp libraries). Indeed the newest
image picked up the newer Alpine release (3.20), which is based on a newer musl
release (and apparently that's a problem !?).
Hopefully the proper python dependencies will become available at some point ?
- more recent sedlex fixes a bug that needed a workaround in our code
- we need recent dates_calc to avoid extra runtime dependency on `Str` that our
build system won't handle
Not much there at the moment, but being able to specify the include directories
is already pretty useful to run clerk directly e.g. on `catala-examples`.
(you had to explicitely specify variable `CATALA_INCLUDE`, the `-I` flags or to
go through `make` without that)
This relies less on specific color flags of GNU diff, and reformats and
colorises the output.
(it may still depend on the specific layout of GNU diff with the `-y` flag
though)
First I was disappointed that we couldn't convert closure environment properly
because of their opaque nature (native/interpreted conversion is based on the
Catala types) ; but after more thought it's actually unnecessary to convert them
at all since we are guaranteed that they can't be consumed outside of their
realm.
it's much simpler to handle down the line if they have a uniform structure;
empty tuples are easily converted into unit types when translating to OCaml.
This avoids differences in test results depending on wether closure conversion
is enabled or not: the functional values within structure are a different type
internally but with this patch they are printed the same.
Support for manipulating toplevel functions as values was buggy, because the
recursion after eta-expansion would fall into the pattern for a `let..in` and
not do the expected transformation.
The patch explicitely builds the closure in that case, avoiding such issues with
recursion.
