NOTE: This is a temporary solution
A future approach could be to have Catala generate a module loader (with the
proper hash), relieving the user implementation from having to do the
registration.
This includes a few separate changes:
- pass visibility information of declarations (depending on wether the
declaration was in a ```catala-metadata block or not)
- add reasonable hash computation functions to discriminate the interfaces. In
particular:
* Uids have a `hash` function that depends on their string, but not on their
actual uid (which is not stable between runs of the compiler) ; the existing
`hash` function and its uses have been renamed to `id`.
* The `Hash` module provides the tools to properly combine hashes, etc. While
we rely on `Hashtbl.hash` for the atoms, we take care not to use it on any
recursive structure (it relies on a bounded traversal).
- insert the hashes in the artefacts, and properly check and report those (for
OCaml)
**Remains to do**:
- Record and check the hashes in the other backends
- Provide a way to get stable inline-test outputs in the presence of module
hashes
- Provide a way to write external modules that don't break at every Catala
update.
We have temporary files to remove upon `ninja` completion so it's not a good
idea to `exec` without fork. This patch ensures `/tmp/clerk_*.ninja` files
aren't left in `/tmp`.
This is a first step into unifying trace handling. This patch only affects the
interpreter, by delegating trace recording to the already existing runtime
functions.
At end of interpretation, it recovers the registered trace from the runtime, and
prints it.
NOTE: there are some limitations due to this approach, as runtime values going
through this interface have to be converted to the "runtime embedded" type. In
particular, functions can no longer be printed (which makes full sense if we
want it to happen in the same way in compiled code) ; some information, like
types, is lost, but it didn't appear to be used.
Also, a specific printer had to be added for runtime values (but it's very
simple so that shouldn't be a problem).
@denismerigoux I'd like your input on how well this goes for your use-cases.
Further work should probably be cleanup and unification of the runtime logging
interfaces ; there is already code for re-structuring the traces, printing to
JSON, etc. which could be common to runtime and interpreter.
mostly reverting to the ones the interpreter was printing ; for the case of
divisions, we choose to point to the denominator instead of the operator as it's
where the only possible error (division by zero) comes from.
