This case is really acrobatic, because we are interfacing code compiled to
OCaml (from lcalc) with code from dcalc, and the two have a different
representation for default terms. It... seems to work though.
A more reasonable solution, if there are problems with this or it reveals too
fragile, would be to enforce interpreting at the lcalc level as soon as you want
to link compiled modules.
HandleExceptions only takes an array of exceptions, and returns Some if only one
of them is Some, None if they are all None, or raises a conflict error
otherwise.
The compilation of default terms then wraps this in a match (for the result of
HandleExceptions), and an if-then-else (for the justification-consequence in the
None case).
This avoids the complexity of having to handle thunked functions as arguments.
*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.
