# Contributing to Catala The project is open to external contributions, in the spirit of open source. If you want to open a pull request, please follow the instructions below. To ask a question to the Catala team, please open an issue on this repository. You can also join the [Zulip chat](https://zulip.catala-lang.org/) to ask any questions about the project. If you want to contribute to the project on a longer-term basis, or if you have specific competences as a socio-fiscal lawyer or a programming language specialist, please [contact the authors](mailto:contact@catala-lang.org). The Catala team meets over visioconference once every week. Please note that the copyright of this code is owned by Inria; by contributing, you disclaim all copyright interests in favor of Inria. Both the code for the compiler and the examples in this repository are distributed under the Apache2 license. ## Writing Catala code Before writing Catala code, please read the [tutorial](https://catala-lang.org/en/examples/tutorial). You can run the programs of the tutorial yourself by following the instruction in the [README of the `examples` repository](https://github.com/CatalaLang/catala-examples/README.md). Then, it is suggested that you create a new example directory again according to the instructions of this README. Let us now present the typical Catala workflow. First, you need to locate the legislative text that you want to use as a reference. Then, simply copy-paste the text into your source file. First you will have to format the copy-pasted text using Catala headings and articles markers: ```markdown ## Heading ### Sub-heading (the more '#', the less important) #### Legislative atom ``` Please look at the code of other examples to see how to format things properly. While formatting the text, don't forget regularly to try and parse your example using for instance ``` make -C examples/foo foo.tex make -C examples/foo foo.py make -C examples/foo foo.ml ``` to see if you've made any syntax errors. Once the text formatting is done, you can start to annotate each legislative atom (article, provision, etc.) with some Catala code. To open up a code section in Catala, simply use ````markdown ```catala # In code sections, comments start with # scope Foo: ``` ```` While all the code sections are equivalent in terms of execution, you can mark some as "metadata" so that they are printed differently on lawyer-facing documents. Here's how it works: ````markdown ```catala-metadata declaration structure FooBar: data foo content boolean data bar content money ``` ```` Again, make sure to regularly check that your example is parsing correctly. The error message from the compiler should help you debug the syntax if need be. You can also live-test the programs you wrote by feeding them to the interpreter (see the [README of the `examples` repository](https://github.com/CatalaLang/catala-examples/README.md)); this will also type-check the programs, which is useful for debugging them. ## Working on the compiler The Catala compiler is a standard dune-managed OCaml project. You can look at the [online OCaml documentation](https://catala-lang.org/ocaml_docs/) for the different modules' interfaces as well as high-level architecture documentation. ### Installing and using nix We provide an nix environement to develop the Catala compiler. It is available after [installing nix](https://nixos.org/download.html). You can then just use `nix develop` to enter the environment. ### Example: adding a builtin function The language provides a limited number of builtin functions, which are sometimes needed for things that can't easily be expressed in Catala itself; in case you need more, here is how one can be added: - Choose a name wisely. Be ready to patch any code that already used the name for scope parameters, variables or structure fields, since it won't compile anymore. - Add an element to the `builtin_expression` type in `surface/ast.ml` - Add your builtin in the `builtins` list in `surface/lexer.cppo.ml`, and with proper translations in all of the language-specific modules `surface/lexer_en.cppo.ml`, `surface/lexer_fr.cppo.ml`, etc. Don't forget the macro at the beginning of `lexer.cppo.ml`. - The rest can all be done by following the type errors downstream: - Add a corresponding element to the lower-level AST in `shared_ast/definitions.ml`, type `Op.t` - Extend the generic operations on operators in `shared_ast/operators.ml` as well as the type information for the operator - Extend the translation accordingly in `desugared/from_surface.ml` - Extend the printer (`shared_ast/print.ml`) - Finally, provide the implementations: - in `dcalc/interpreter.ml`, function `evaluate_operator` - in `../runtimes/ocaml/runtime.ml` - in `../runtimes/python/catala/src/catala/runtime.py` - Update the syntax guide in `doc/syntax/syntax.tex` with your new builtin ### Internationalization of the Catala syntax The Catala language should be adapted to any legislative text that follows a general-to-specifics statutes order. Therefore, there exists multiple versions of the Catala surface syntax, adapted to the language of the legislative text. Currently, Catala supports English, French and Polish legislative text via the `--language=en`, `--language=fr` or `--language=pl` options. To add support for a new language: - the basic syntax localisation is defined in `compiler/surface/lexer_xx.cppo.ml` where `xx` is the language code (`en`, `fr`...) - copy the files from another language, e.g. [english](compiler/surface/lexer_en.cppo.ml), then replace the strings with your translations. Be careful with the following: - The file must be encoded in latin-1 - For a given token `FOO`, define `MS_FOO` to be the string version of the keyword. Due to the encoding, use `\xNN` [escape sequences](https://ocaml.org/manual/lex.html#escape-sequence) for utf8 characters. - If the string contains spaces or non-latin1 characters, you need to define `MR_FOO` as well with a regular expression in [sedlex format](https://github.com/ocaml-community/sedlex#lexer-specifications). Replace spaces with `", space_plus, "`, and unicode characters with `", 0xNNNN, "` where `NNNN` is the hexadecimal unicode codepoint. **Hint:** You may get syntax errors with unhelpful locations because of `sedlex`. In that case the command `ocamlc _build/default/compiler/surface/lexer_xx.ml` may point you to the source of the error. - add your translation to the compilation rules: - in `compiler/surface/dune`, copying another `parser_xx.cppo.ml` rule - in the `extensions` list in `compiler/driver.ml` - add a corresponding variant to `compiler/utils/cli.ml` `backend_lang`, try to run `make build` and follow all type errors and `match non exhaustive` warnings to be sure it is well handled everywhere. - you may want to add syntax highlighting support, see `syntax_highlighting/` and the rules in `Makefile` - add examples and documentation! Feel free to open a pull request for discussion even if you couldn't go through all these steps, the `lexer_xx.cppo.ml` file is the important part. ### Example: writing custom backends as plugins Catala has support for dynamically-loaded plugins to use as alternative backends. See `compiler/plugins` for examples, and [the documentation](https://catala-lang.org/ocaml_docs/catala/plugins.html) for more detail. ### Automatic formatting Please ensure to submit commits formatted using the included `ocamlformat` configuration. The `make build` target should ensure that. In case the formatting rules or ocamlformat version changed remotely, you can use [this script](https://gist.github.com/AltGr/2891a61f721c8fd85b1da71e10c691b6) to reformat your branch patch by patch before rebasing. ### Hand-updating packages in the nix part Requirements of catala that are not inside [nixpkgs](https://github.com/nixos/nixpkgs) are available inside the `.nix` directory of the repo. The main part is inside the `.nix/packages.nix`, where all the packages are either added (because absent from nixpkgs) using `ocamlPackage.callPackage`; or modified from nixpkgs, for instance cmdliner is currently pinned at version 1.1.0. ### Pull Requests Policies Pull requests must be approved by, at least, one knowledgable contributor before merging. Unless there exists legitimate reasons, every commit of the pull request must compile, and, the final commit must successfully pass the CI check. All requested changes should ideally be included in the PR. However, if the PR is merged while there are still open discussions or if there are late remarks, it should be addressed as soon as possible in a follow-up PR. As much as possible, offline interactions between the author and reviewer(s) leading to a discussion resolution should result in a quick summary that documents the decision. Whenever major changes are requested, both PR's author and reviewer(s) may reach an agreement to delay the resolution (e.g., in a future PR) in which case it must be documented as an issue in order to properly track it.