split the generator to its own project

[brabalan]

Since the generator is also used by MLExplain (https://github.com/Docteur-Lalla/mlexplain/tree/mlexplain), it would make sense to split it to its own project.

[IgnoredAmbience]

This makes a lot of sense. It would also make the packaging simpler to use.

The monadic binder ppx will need some consideration: the configuration of the bindings should be made configurable without being compiled in. One possibility could be to annotate the function definitions in JsInterpreterMonads with attributes to indicate that the function is a monadic binder, and configure which tag it should be applied with? Eg: let if_value ... = ... [@@binder 'value']? (Exact attribute syntax tbc). Alternatively we could pass a module name as a configuration option and simply bind any binder to a function of the same name in the given module.

We previously removed the hard dependency on the looking up binder names inside the generator in 762ff39, we now instead tag the replaced binders with attributes which then allow the call to be detected as monadic.

[brabalan]

I like the tag approach, but I'm not sure to see how it would work.

[barockobamo]

What should be the name of the generator project ? Should it be a sub-project of JSCert ?

[brabalan]

How about fjs_of_fml?

[IgnoredAmbience]

I don't mind about naming. If a new repo is required underneath the @jscert organisation, then either myself or @brabalan can create a new one, although we should probably lift your user permissions to be an organisation team member?

[brabalan]

Yes, we should upgrade Samuel's permissions.

[IgnoredAmbience]

Organisation permissions updated.

[barockobamo]

Generator repository created ihere : https://github.com/jscert/fjs_of_fml